Let's say we have an admin that wants to invalidate all user tokens (effectively logging the user out everywhere), but without blocking his account. The user should still be able to log in normally.
Example:
clientIds.forEach(clientId -> {
Collection<OAuth2AccessToken> accessTokens = tokenStore.findTokensByClientIdAndUserName(clientId, username);
accessTokens.forEach(accessToken -> tokenServices.revokeToken(accessToken.getValue()));
});
This works fine ONLY IF access tokens are still valid (not expired), because access tokens are found and based on them, revokeToken invalidates both access and refresh tokens. However, if access token is expired, findTokensByClientIdAndUserName does not find anything, thus nothing is invalidated and refresh token is still valid and ready to be used.
I've looked everywhere, and it looks like everyone revokes refresh tokens either by using access token or by passing refresh token value as request parameter.
Is it possible to find refresh token without using access token?
You can implement yourself the TokenStore interface and add a method such as:
OAuth2RefreshToken findRefreshTokenByUserName(String userName);
Related
After getting first access token (and refresh also) with user login and password I need them to no longer be available to get access token. It has to be done only with refresh token every time. Is it possible in Keycloak?
Thanks in advance!
I'm working on a SPA app based on Node, with token-based authentication using JWT. Right now, the jwt token never expires, which is not good.
I want it to expire for more security, but I don't want my users to be forced to re-log. That's why I need a refresh token.
So i'm reading about OAuth2.
I have a hard-time to understand why refresh-tokens must be stored in a database, whereas access-token are generated on the fly using a secret key.
Why refresh tokens can't be generated the same way as access tokens ?
Thank you guys !
Refresh tokens usually are generated the same way as access tokens.
An authorization server will often return a refresh and access token if requested (and you're not using the implicit grant type).
The difference is how they are used.
An access-token is usually a bearer token: whoever has it can use it against the resource server, but it is only valid for a short period of time. In which case, storing them in a database is often pointless as they are worthless once expired.
A refresh token however is like having access to a "forge" which allows you to mint a new token.
If you present the refresh token to the authorisation server (not the resource server) you will get back a new access token and possibly a new refresh token.
Providing of course that the user has not revoked/changed access permissions to your application and that the user is still a valid user.
So you would keep them in a database perhaps because your user logs in infrequently. So you may need the refresh token weeks after you got it.
Alternative to the refresh token.
If you are using the implicit grant (which is common with SPAs but not recommended). You can try and keep your end user logged in to the identity provider used by the authorisation server. This way you can keep requesting new access tokens from the auth server without the user being prompted by the auth server for credentials as a session will be persisted between the identity provider and the user's browser.
Once I've completed the OAuth flow by obtaining authorization from the user and then creating an access token, how do I obtain another token without asking the user for authorization again? I thought the user's account on Smartsheet would remember that they trusted the application, but that doesn't seem to be the case. I'm new to OAuth so I'm sorry if I'm missing something obvious.
Thanks!
Access tokens retrieved via the OAuth flow are valid only for a certain period of time -- you (i.e., your application) can refresh a token before it expires in order to prevent the end-user from having to provide authorization again.
When you issue a GET Token request to obtain an access token, the response contains not only the token itself, but also information to indicate how long the token is valid (the expires_in property indicates the number of seconds until the token expires) and a refresh_token property value that you'll need in order to refresh the token.
To prevent the user from having to provide authorization again, simply refresh the token before it expires, and then use the new (refreshed) token value in subsequent API requests. Note that each token you obtain (whether it's the original token or a refresh token) will always expire in a finite amount of time, thereby requiring that you refresh the token in order for your application to maintain user authorization.
I am building a (set of) web application; the backend has REST-like API, the frontend will be some REST JS app, android apps etc; and I'm trying to come up with an SSO functionality.
Looking at Oauth2/OIDC it seems the best way would be to use Implicit flow; however, the access tokens in implicit flow (in oidc) have a set expiration. The refresh token is not part of implicit flow.
How do I ensure that the user will stay logged in? I.e. when the access token expires, the frontend application will try to obtain a new one from an auth server; that is supposed to ask for username/password. Alternatively, it can build a session with the frontend (using cookies), but how is that different from a refresh token?
It seems to me that getting the access token e.g. from the android app means at least opening the web browser; depending on the expiry length, that could be quite often. Is that the correct flow or am I missing something?
You are right, the issuance of a refresh token is not allowed with the Implicit grant type.
However, the refresh token and the access token are not needed to know if the user is logged in or not (the access token only allows you to access on protected resources). You have to use the ID Token which is issued in the authorization response.
You can verify if the user is still logged in by sending an authorization request with the query parameter prompt=none (see section 3.1.2.1. Authentication Request). I recommend you to send the current ID Token using the id_token_hint query parameter as mentioned in the same section:
ID Token previously issued by the Authorization Server being passed as a hint about the End-User's current or past authenticated session with the Client. If the End-User identified by the ID Token is logged in or is logged in by the request, then the Authorization Server returns a positive response; otherwise, it SHOULD return an error, such as login_required. When possible, an id_token_hint SHOULD be present when prompt=none is used
If you receive an error (login_required or interaction_required) then the user may be logged out.
Another way could be to use the Session Management feature. But as this specification is not yet approved (draft 27), it may be subject to changes and may not be available. However it is a very simple way to know the status of the user.
I am trying to get access tokens from OAuth.io for any Google based provider however whenever I authenticate I get an access_token but no refresh_token. I have chosen offline for the access_type but still no joy.
I have tried looking through the documentation for a solution but it barely covers anything related to the refresh token.
To get the refresh token from Google, you need 2 things:
The offline option
cf https://developers.google.com/accounts/docs/OAuth2WebServer
"A token that may be used to obtain a new access token. Refresh tokens are valid until the user revokes access. This field is only present if access_type=offline is included in the authorization code request."
The option approval_prompt set to "force"
cf https://developers.google.com/accounts/docs/OAuth2WebServer
"Important: When your application receives a refresh token, it is important to store that refresh token for future use. If your application loses the refresh token, it will have to re-prompt the user for consent before obtaining another refresh token. If you need to re-prompt the user for consent, include the approval_prompt parameter in the authorization code request, and set the value to force."
so your script should look something like
OAuth.popup('google', {
authorize: {
approval_prompt: 'force'
}
}).then(function(google) {
console.log(google.refresh_token)
//send the refresh token to your server
})
If you are working client-side (Javascript / iOS / Android / Phonegap), you may also need to activate the following option: Send refresh token to front-end in the OAuth.io dashboard > General > advanced option to allow your client side SDK to retrieve the refresh token
https://jsfiddle.net/Lqyc5jpw/