I am trying to impliment Oauth for my webapplication for google.I am worked upon a POC and it working fine but i have a confusion and not sure how best it can be achieved.
I am using scribe java API for Oauth.
here are the steps i am performing.
Getting request token from Google.
Redirecting user to Google to authenticate them self and authorize my serivice to access his/her few details.
get Access Toekn from google by providing request token and verification code given by google.
Accessing user info once google provide Access token.
now my main confusion is at step no 3, since i am working on a web-application so it will be a 2 step process.
Redirecting user to google
Handling back google redirect.
In order to get an Access token i need to provide same request token which i got at step1 else my request being rejected by the user.
The request token contains 2 things
Toekn -->which is based on the registered application so not an issue
Secret-->This is always being a random string so it should be same when asking for access token
that means i need to store this secret either in my session or some where so that i can access this secret when user is being redirected back to my application.
My confusion is,since in order to save it in session i have to create a unique key and some way to access it in the other action class which will handle Google Redirect back how can i achieve this since at a given time so many user can ask to login using google.
any help in this regard will be much appriciated.
Thanks in advance
When you receive the request token + token secret, use the request token as the unique key of your session to store the token information. After the authorization process, in the callback url, you have access to the request token (it's one of the parameters passed to the callback url). Using this parameter as the session key, you can restore the token information from session, including the token secret, and use it to sign your request for changing the request token for access token. After receiving the access token, a new token secret is returned to you and you can delete the old one from session.
how can i achieve this since at a given time so many user can ask to
login using google
This is not of any problem because for every single user on your site, you are given a different request token.
Related
I am not clear on what exactly I should do with the id token from Google after the initial verification.
I'm developing on expo/react native and get the id token locally. Then, I send it to my server and verify it using google client libraries. Once it's verified what should I do with it?
Ideally I could use it to protect my api routes (express) but id tokens expire after 1 hour and I'm not sure how to refresh them with the client library. So, I don't know how I would do this.
Is that the intended use for id tokens? Should I instead be signing my own jwt and sending that back to the client? Then, the client could send that in the auth header of each request to a protected routes.
Google says:
After you have verified the token, check if the user is already in your user database. If so, establish an authenticated session for the user. If the user isn't yet in your user database, create a new user record from the information in the ID token payload, and establish a session for the user. You can prompt the user for any additional profile information you require when you detect a newly created user in your app.
https://developers.google.com/identity/sign-in/ios/backend-auth
Do I use the id token to "establish a session for the user"?
Yes, the ID-token is only used to create the local session, perhaps also create a local entry in your local database if that is used.
The ID token also have a very short lifetime, like 5 minutes in some systems. So it has no long-term use.
The ID token is intended to authenticate the user. It gives you information about the authenticated user, it should not be used to allow access to your endpoints. Access tokens or sessions are intended to do so. So in your case, you should do exactly as your gut feeling tells you - create a session for the user basing on the data you got in the ID token.
If you have your own Authorization Server you can use the ID token to issue an access token and return the token to the frontend app, then use the access token to access your backends. Have a look at OAuth flows if you would want to go this way.
After users sign in, grant permission, and redirect back to my app. I got something like this
{"state"=>"xxx",
"code"=>"yyyy",
"id_token"=>"zzzz",
"user"=>"{
....
}"}
Which is everything I need to create a user account, but the OAuth flow isn't finished yet. For a normal flow, we would use that code to fetch access token from https://appleid.apple.com/auth/token
https://developer.apple.com/documentation/signinwithapplerestapi/generate_and_validate_tokens
My question is, should I do that? It seems to add no value to the current situation.
Basically generate_and_validate_tokens is only if you are using web-based login. If you are using Authenticationservices, then framework handles all the authorisation logic for us. Hence fetching access token from https://appleid.apple.com/auth/token is not required.
Apple is returning id_token directly after user authorization in the call-back response if you request for it, which seems to be your case as well. If you just need users identity to create an account or sign in the user to an associated account on your side, you do not need to fetch access/refresh token by exchange code against the /token api. Just make sure to validate the id_token as mentioned in Verify the Identity token before getting the user details from it.
Exchange of authorization code for access/refresh/ID token will be necessary if you do not request id_token in the initial authorization request and you need users identity to proceed. You can then fetch it as per Retrieve the User’s Information from Apple ID Servers
I'm new to OAuth2 and I'm trying to understand the whole flow of things. For context, I'm thinking of making a web dashboard where users log in via Discord's OAuth2 API.
This is how I think the flow works based on my understanding so far:
User goes to my site and clicks a login link
My site redirects them to Discord with my client ID and a redirect URL #1 in the query string
Discord redirects them back to my site at redirect URL #1 with an authorisation code in the query string
My site takes this authorisation code and along with my client ID, client secret and redirect URL #2, uses all these to fetch an access token and refresh token from Discord
If I do get an access token, that means the user is now "logged in" (authorisation code worked)
My site finally redirects the user to a page and is now free to send requests to Discord's API with the access token, while saving the access token and refresh token. Just for example, say the page states their Discord username
I'm learning from this guide, and what confuses me is this code snippet from the guide. At line 5, it provides the redirect URL #2 mentioned above, in the query string. I'm not sure what it's for.
Also, I'm not very sure how to continue once I have the access token. If multiple users log in, I'd have multiple access tokens on hand. Say a user wants to access the page again, how do I uniquely identify them and know which access token to use to send requests to Discord's API? (for this example, the request would give me their username which I'd display on the page)
Yeah, I probably got a lot of concepts wrong. Any clarification would be greatly appreciated!
Edit: I've done more research into this, and found a much better guide here.
For my question about the second redirect URL, the examples in the official documentation specify a redirect_uri when doing both an access token and a refresh token exchange. However, this new guide makes do without for their access token exchange. Perhaps they missed it out? As this other stack overflow question says:
As an added measure of security, the server should verify that the redirect URL in this request matches exactly the redirect URL that was included in the initial authorization request for this authorization code. If the redirect URL does not match, the server rejects the request with an error.
I suppose this means that after the first access token exchange, any refresh token exchanges or straight up API requests with access tokens need to match the original redirect_uri of said first access token exchange. So I should use one and only one redirect_uri, and the refresh token exchanges/API requests do not actually use the redirect_uri, rather it's used for further security.
As for the whole login procedure, it seems I have to link the access & refresh tokens I obtain to a user session, and for that I'll look into using this passport strategy, passport-discord. Then, once the session expires, I'll discard the two tokens, and they'll have to click login again, but I can make use of this prompt option:
prompt controls how the authorization flow handles existing authorizations. If a user has previously authorized your application with the requested scopes and prompt is set to consent, it will request them to reapprove their authorisation. If set to none, it will skip the authorization screen and redirect them back to your redirect URI without requesting their authorization.
From there I think I'd just store the new access and refresh tokens associated with that user.
I'd really appreciate if any mistakes in my thought process could be pointed out!
Your summary seems good to me Mr Cloud - worth clarifying whether you are developing an SPA or (old) web app with a server side. Most commonly the first is cookieless, whereas the second stores a refresh token in a cookie. A key thing is to understand what the OAuth message workflow looks like. For SPAs and APIs this write up of mine may help you clarify what you want: https://authguidance.com/2017/09/26/basicspa-oauthworkflow/
Happy to answer any follow on questions ..
You can use the implicit grant to use with SPA
https://discord.com/developers/docs/topics/oauth2#implicit-grant
I need to access several YouTube channels for my job to pull analytical data and export it to a database. The problem, is that this requires using OAuth, which would be fine except I don't know the controlling person's username/password. She probably won't give me her credentials since it's personal.
Is there a way to do this without explicitly using her username/pass? Like, she tried making me a content owner, but I still can't authorize this level of information.
This is exactly the reason why OAuth was created, to make requests on behalf of a user without their username and password.
Have that user generate an access token. Here are the Google Docs. In a nutshell:
Have your user send a post request to https://accounts.google.com/o/oauth2/token with your app key. The response should look something like:
{
type: "oauth",
token: "XXXXXXX"
}
Then, make an API request on behalf of that user with their token by passing in the token returned from the previous step as value for the Bearer filed for any web request to the YouTube API. This will allow you to perform an authenticated request without explicitly knowing the user's username and password.
I'm developing a Twitter application on OAuth and I want to provide the ability to post updates in the future.
The basic plan is to run a script every hour and find any updates which need to be posted, and then authenticate the appropriate user and use the statuses/update API call.
However, I don't know how I can use OAuth for this. I obviously don't want to store their username and password - that defeats the object of using OAuth in the first instance.
If, though, that is the only option, then how can I not store a plaintext copy of their password but still authenticate them?
With OAuth you only need user credentials initially to get the oauth token. After you have the oauth token, you use the oauth token in place of those credentials. The only issue in subsequent calls under OAuth is any TTL (time-to-live) associated with the token on the service-side. Twitter does not apparently expire tokens, so once you have a valid token you should be able to continue to make calls on behalf of the user. The only times you would need to get credentials from the user are (1) in the initial stages of running the application, or (2) if the user's session becomes invalid for some reason (changed password, user-directed invalidation of the session, etc.).
See the OAuth spec for more details.
Note that should you intend to use the same user token between invocations of your application, you should be prepared to encrypt the token and store it securely. Should someone capture your consumer key and secret, along with the user token, the identity of the user can be compromised.