So I'm trying to use Google Sign In and Sign in with Apple in my native mobile app which also communicates with my own backend server. I think I have the grasp of the OAuth2 flow and the concept of ID Tokens behind OpenID Connect. The only doubt I have is if I can/should use the access/refresh token pair to authorize access to my own endpoints? On apple's documentation this isn't clearly stated and on Google's site they mention you CAN use it to access Google APIs, but nowhere have I found you could use it for your own backend server. If not, how should this be approached (generating my own access/refresh token pair after validating the the authorization server's ID Token?)
Note that I only need to authenticate my users via these platforms, I don't want access to other Google APIs (for now).
TL;DR: Can I use Apple's/Google's access/refresh token pair to authorize access to my own backend's endpoints or should I generate my own/do something else?
You can use the tokens provided to you, but often you soon or later will want to customize what they contain and then introducing your own local provider can be a solution. So that your internal services trusts the tokens from your own service an your auth server trusts the tokens from Apple/Google.
The second problem is that your internal systems might need to trust multiple token issuers. In my experience is to internally only trust one token service and not multiple, even if this is not a hard requirement.
Related
I have two web applications that I've worked on in ASP.net Web API for a client. The two applications are hosted on the same domain, but in different virtual directories.
Each application has a data source with information about authorized users. I've been asked to set up a separate app that will allow a user to log in and issue an OAuth bearer token that can be used to access each web application.
I have the Owin stuff set up in one of my two apps with something of a boilerplate setup and it automagically makes the tokens work for me, but that's only within a single web application.
I have a general idea of how the OAuth tokens work: a user is authenticated and they receive a token that contains a user ID, a time stamp, and a cryptographic signature that says that the token came from my client's server and not somewhere else, and the Web API framework automatically checks that token for me when I decorate my API endpoints with the [Authorize] attribute.
I want to know how I can set this up so that the token is issued by one web app and consumed by another. I know that at a minimum, I need to make the two web apps work with the same key pair for the cryptographic signatures.
Can I please get some direction about how to make this happen?
I've found plenty of information on implementing Oauth2 using a user authorization step, but I'm trying to run a container that automatically scrapes a gmail inbox for attachments transforms them, and exports to prometheus, and I'm having trouble figuring out how to implement this library: https://pkg.go.dev/golang.org/x/oauth2/clientcredentials#Config or any other for that matter to retrieve a token without involving a manual user step.
Will doing this in Go require writing direct API calls since I can't find an existing library to handle this scenario? Would it make more sense to create a Google App password and use generic user/pass SMTP authentication?
First off i understand what you are trying to do.
You have a backend system running in a container which will access a single gmail account and process the emails.
Now you need to understand the limitations of the API you are working with.
There are two types of authorization used to access private user data
service account - server to server interaction only works with workspace domains. No authorization popup required.
Oauth2 - authorize normal user gmail accounts, requires user interaction to authorize the consent screen
If you do not have a workspace account and this is a normal gmail user then you have no choice you must use Oauth2, which will require that a user authorize the application at least once.
Using Oauth2 you can request offline access and receive a refresh token which you can use to request new access tokens when ever you wish. The catch is that your application will need to be in production and verified, because your refresh token will only work for seven days and then it will expire. To fix this and get a refresh token that does not expire means that your application must in production and verified. This means you need to go though Googles verification process with a restricted gmail scope which requires third party security check and costs between 15k - 75k depending upon your application.
I understand that this is a single user system but that does not mean that you still need to go though verification. When google added the need for application verification they did not take into account single user systems like yours.
Option
Have you considered going directly though the SMPT server instead of using the Gmail api? If you use an apps password you should bypass everything by loging in using the login and the apps password.
Im trying to find some best practices on how to solve my problem.
I have a microservice application with oauth2 and firebase for authentication and authorization.
Our application needs to connect to a 3rd party rest api which is secured with oauth2 as well.
Is it possible to integrate both implementations or do i need to make my own solution?
One of my co-workers implemented the authorization-code flow needed to access the api and we basicly store access and refresh_tokens in the database to access this 3rd party api. But it doesn't feel right, i cant find any best practices either, can anyone help me out?
What your co-worker implemented is pretty typical: separating out the authentication and authorization for your own application (which you manage with Firebase) from your users authorizing your use of the 3rd party API.
Here are some best practices you should be following when implementing your OAuth flow:
Use the state parameter to avoid CSRF attacks. Store it in your database and compare the callback state with the one that you randomly generated for the user
Encrypt access and refresh tokens. Refresh tokens in particular provide long-lived access
Verify that the scope you asked for is the scope that was returned: some providers allow users to adjust the permissions, which can lead to unexpected errors
Make sure your refresh tokens don't expire. Check with the provider's docs to see how refresh tokens are deauthorized. Some are time-based, some are based on new refresh tokens being issued, but in any case, make sure your refresh token stays valid, as if it is not, you must get the user to re-authorize your application
You can also use a managed OAuth provider to abstract away all these elements. Xkit, which I work on, integrates with Firebase Authentication so your users can authorize your app, and you can retrieve each user's tokens with one API call.
Situation
Using the Google Core Reporting API (v3), I need to get client companies analytics and other data but since they are organizations and not individuals, It is too tedious to put them through the login flow in order to get access tokens.
I know that I can obtain a token for such a request using the Server to Server auth process, but that involves obtaining and holding on to their private key which then grants me, to my knowledge, near unlimited access.
Question
Is the Server to Server method the only way to do this or is there something better.
Yes, server to server is the only method which doesn't require the client login (OAuth).
Remarks about Google APIs:
Server-to-server comes in 2 flavours: Service account and API key
The vast majority of Google APIs (including Google Analytics APIs) only support the Service account method for server-to-server access
Some (eg Google Search Console) support API keys instead of Service account
You could use OAuth and store refresh tokens so people don't have to authenticate every time should you want to use a method that requires client login
Remarks about GA:
You should use the v4 reporting API as v3 is being discontinued
I am building a mobile app in which the users need to be authenticated via TrueVault which is a HIPAA compliant data store. TrueVault offers a REST API and generate an access token post basic authentication. They have endpoints to check token validity etc too.
We need to do 2 things:
1) Authenticate all users via TrueVault and store the auto generated TrueVault id in Parse to facilitate data mapping.
2) Setup an interceptor in Parse which verifies the access token with TrueVault before serving any protected resource.
What would be the simplest and most efficient way to implement the above? I have gone through the tutorial to add Third Party oAuth to the mobile apps, but TrueVault does not have oAuth in place yet and thus needs authorization requests via Basic Auth only. Also, would we need Cloud Code for the above or Custom Web Hooks?
Thanks
Sameer
i would suggest you to use retrofit, Gson(or jackson) and rxjava(rxAndroid) in order to handle all api calls, i made a quick overview to the api documentation and this libraries should work for this problem.
links:
https://github.com/square/retrofit
https://code.google.com/p/google-gson/
https://github.com/ReactiveX/RxAndroid
Cheers.