I understood that Refresh Token is used to get another access token after it expires. But, I am confused about how to use it.So, here is what my code looks like(I am building a app with Twitter API and the app uses Oauth2.0 authorization):
User sends request to my API server with access token and refresh token(stored in cookies)
In my server, when I make request to the Twitter API, first I request with access token--if the request is unauthorized(due to expired access_token) I use refresh token to get another access token and use that to make request.
This 2) codeblock for everytime I make a API request to the Twitter API is infuriating me. What is the better way to write. Am I doing something wrong.
You haven't included your code, so it's impossible to tell what might be incorrect about it. However, the process for using a refresh token is pretty straightforward. See here (under Refresh tokens near the top) and here (at step 5) in the docs.
Essentially, you will make a POST call to https://api.twitter.com/2/oauth2/token with a URL-encoded body. You will include the refresh token and a grant type of refresh_token in that body. Depending on whether your app is a confidential client or not, you'll include the client ID in the body or in the header with a client secret.
Whatever code you are using for the access token should be easily reusable with a few tweaks.
Related
I'm new to webdev and have implemented access token & refresh token based authentication in my express project. However, the more I look over the implementation I'm starting to question why access tokens exist when it appears that refresh tokens make them redundant. Perhaps it's just my implementation.
For any task that needs authentication, I send off a cookie with both an access token and refresh token to an auth server. It looks at the access token, and if it is both valid and unexpired, it will send a 200 back and allow any express middleware to continue on.
However if it has expired, it will then query a database to see if a matching refresh token exists and, if so, will send a new access token.
As the lifetime of the access token decreases, the auth server will need to do more database searches to verify the refresh token. At that rate, why bother with the access token and instead why not rely solely on the refresh token? After all, the refresh token can be removed from the database and the authorisation server can reject any requests made with it.
The only reason I can think of the access tokens existing is to reduce how often a page will need to query a database, but that seems too simple. Since I'm fairly new to this, I know I must be missing some larger concept. Can anyone enlighten me?
I have a Keycloak server setup with a realm and a client. I have Authorization setup on the client and I'm able to evaluate the authentication within the admin interface.
When I click "Show authorization data", I can see in the response an authorization attribute with permissions.
I have a web client that uses a redirect via keycloak for oidc authentication. I would like to limit which keyclock users are able to login into the client, so I would like to authorise the login, but I'm unable to see the authorization attribute in the JWT.
Am I completely misunderstanding how this works, or is there something I can do to see that attribute?
OK, I've finally go my head around it. Short answer - I needed to RTFM.
Long answer - I needed to hit the token endpoint twice. The first time with grant_type = authorization_code to get the access token. Then again with grant_type = urn:ietf:params:oauth:grant-type:uma-ticket (and with the access token in the header) to get the keycloak client to authenticate.
If the second response comes back as 403 - access_denied, then I reject the login, otherwise, I allow the user to login into my system.
The specific bit I needed can be found in the docs is here: https://www.keycloak.org/docs/6.0/authorization_services/#_service_obtaining_permissions
My simple application written in Javascript is using a service (which is written as a wrapper on Auth0) for authentication. On successful login, if I refresh the home page, application again goes to login page (even if I have stored the access token in cookies)
I also tried to store the access token in browser session storage.
As my index.html is launched, i am checking if my application url contains access token. If there is no access token, I redirect it to login page.
if (((window.location.hash).indexOf('access_token') < 0)) {
location.replace(redirectUrl);
}
On successful login, as url has access token in it, app works fine further.
But next time when I refresh the home page, it don't have access token in URL.
As per my understanding, as I have access token in cookies, it should not ask me for login again as long as token is valid.
It is still asking for login. What should be the strategy should I use to persist the token ?
On logout, I am setting the cookie to expire. Is there any ideal way to do log out other than this?
This can often be troubleshooted with a HAR file capture to follow the trail being left in the authentication flow. However since we don't have that option at this juncture here are a couple things to look at.
Are you using Dev keys in your auth scenario?
Expiry time
Where is the access token being stored?
https://auth0.com/docs/tokens/overview-access-tokens
Currently, you have a somewhat incomplete implementation.
As per my understanding, as I have access token in cookies, it should not ask me for login again as long as token is valid.
Saving token in the cookie storage and local storage does not have any relation with user authentication state. It is just a way of persisting the token and reading the data. In each navigation, you need to read the token and extract the information from the token to make sure user is authenticated.
The architecture you should follow:
Redirect the user to /authorize endpoint if there is no valid token in the application.
Once auth0 finish the user validation, the user will be redirected in the whitelisted callback URL. Make sure this URL is unique and save the token from URL fragments. It is very important to complete the token validation on the client side. Otherwise, it will be a major security issue. https://auth0.com/docs/tokens/guides/id-token/validate-id-token
Redirect the user to the secured URL.
I would highly recommend using auth0 SDK as it mitigates all the security issues including token signature validation using RS256 algorithm.
https://auth0.com/docs/quickstart/spa/vanillajs/01-login
You may find folloiwng thread useful
Why my auth0 token expires when refreshing page or clicking link in my Angular app?
I have a problem understanding the principle handling of oauth 2.0 tokens.
My scenario is, I have a web based frontend backend system with node.js and angular 2.
A user should be able upload a video on this site. Then some additional metadata is created (dosen't matter for this question). When that is done, the user could upload the video to youtube with the additional data by clicking on a button.
My question is how many tokens/credentials are there in this process. The youtube api needs an oauth token. Does the user also have its own token?
Here is the tutorial I used:
https://ionicabizau.net/blog/14-uploading-videos-to-youtube-using-nodejs
As you can see one token for the API is created for local testing. But is this token generated in a different way in a live version? And how is the user of my website recognized. Also via this token? Or do I have to generate a second token for him?
I am not sure what you mean by 'Token'.
In order to access any Google API you will first need to register your application on Google Developer console. You will then need to create Oauth2 credentials. Oauth2 credentials is were your application will request access from a user to access the data on their YouTube account.
On Google Developer console you will need to save the Client id, client secret and the redirect uri. All three will be needed by your code to authenticate the user.
When the user grants your application access to their YouTube data. You will get an access token and a refresh token back from the authentication server. Access tokens are short lived about an hour and are used to make requests (like upload) to the API. A refresh token can be used to request a new access token once the one you have currently has expired.
You will probably end up with the following:
client id, client secrete, redirect uri, and a refresh token.
If you are interested I have a tutorial that is part of my Google Development for beginners tutorial series that explains Oauth2 and how it works.
An access token is generated from the Server side and sent back to client from where the access request is generated. For all the subsequent requests you need to pass the access token which will be verified with the signature of the token saved on the server to check the authentication of valid requests. You will only get 1 access token which will be used.
You can also use "Refresh" tokens in case you need to keep your access tokens valid for longer duration.
I am implementing Google authentication into my JavaScript web application. I would like to use the authentication code flow as described here.
What I want to do is...
User clicks a button and gets presented with the consent screen
He clicks "allow" and I get back the authorization code
I send the authorization code to my rest backend in order to exchange the authorization code to a access_token
The first 2 parts working perfectly as expected but I cant get 3. to work.
I call https://www.googleapis.com/oauth2/v3/token from my backend posting the code, client_id, client_secret, redirect_uri and grant_type (authorization_code). This works well, I checked it with fiddler (a web debugging tool). However I always get unauthorized_client as a result.
Any ideas?
After a lot of testing and reading i finally got it.
Even if i perform a POST request to get the access token in my backend i need to pass in the parameters (client_id, client_secret, etc...) with the query string NOT the body.
I need to provide the same redirect_uri in both requests (getting the code and getting the access_token)
Now it works great.