I already know what is different between stateless/stateful Access Token.
What is different between stateless/stateful Refresh Token? is the same as Access Token?
Why Google and Auth0 use stateful refresh token?
Why Keycloak use stateless refresh token?
example keycloak stateless refresh token
eyJhbGciOiJIUzI1NiIsInR5cCIgOiAiSldUIiwia2lkIiA6ICI3ZTVmNzhhYy05ODVmLTRjMTgtYmMwYS1kMDJjZDFlOGRhNGQifQ.eyJqdGkiOiJmNTEwMjUxNC0wMGE4LTQzNDEtOTljOC1mNjg3ZjBmOTk0MTMiLCJleHAiOjE1NjY5NzkxMzQsIm5iZiI6MCwiaWF0IjoxNTY2OTc3MzM0LCJpc3MiOiJodHRwOi8vMTkyLjE2OC45OS4xMDA6ODA4MC9hdXRoL3JlYWxtcy9tYXN0ZXIiLCJhdWQiOiJodHRwOi8vMTkyLjE2OC45OS4xMDA6ODA4MC9hdXRoL3JlYWxtcy9tYXN0ZXIiLCJzdWIiOiI0OTEwMGFiZC00ZGFjLTQ5MzQtOTUwYi05N2I0ZGMxYmI5MGMiLCJ0eXAiOiJSZWZyZXNoIiwiYXpwIjoic2VjdXJpdHktYWRtaW4tY29uc29sZSIsImF1dGhfdGltZSI6MCwic2Vzc2lvbl9zdGF0ZSI6IjZiZGUzOWRmLTdhZGYtNDA1ZS04Y2ExLTBiNzQ5YWFlMDdkNSIsInJlYWxtX2FjY2VzcyI6eyJyb2xlcyI6WyJjcmVhdGUtcmVhbG0iLCJvZmZsaW5lX2FjY2VzcyIsImFkbWluIiwidW1hX2F1dGhvcml6YXRpb24iXX0sInJlc291cmNlX2FjY2VzcyI6eyJtYXN0ZXItcmVhbG0iOnsicm9sZXMiOlsidmlldy1yZWFsbSIsInZpZXctaWRlbnRpdHktcHJvdmlkZXJzIiwibWFuYWdlLWlkZW50aXR5LXByb3ZpZGVycyIsImltcGVyc29uYXRpb24iLCJjcmVhdGUtY2xpZW50IiwibWFuYWdlLXVzZXJzIiwicXVlcnktcmVhbG1zIiwidmlldy1hdXRob3JpemF0aW9uIiwicXVlcnktY2xpZW50cyIsInF1ZXJ5LXVzZXJzIiwibWFuYWdlLWV2ZW50cyIsIm1hbmFnZS1yZWFsbSIsInZpZXctZXZlbnRzIiwidmlldy11c2VycyIsInZpZXctY2xpZW50cyIsIm1hbmFnZS1hdXRob3JpemF0aW9uIiwibWFuYWdlLWNsaWVudHMiLCJxdWVyeS1ncm91cHMiXX0sImFjY291bnQiOnsicm9sZXMiOlsibWFuYWdlLWFjY291bnQiLCJtYW5hZ2UtYWNjb3VudC1saW5rcyIsInZpZXctcHJvZmlsZSJdfX0sInNjb3BlIjoicHJvZmlsZSBlbWFpbCJ9.Hsaib16poW3SW0EYUB80jU0HyseZi_Ui9tj_2QJAZ-w
I read this topic Oauth 2: why refresh tokens must be stateful? but I still don't understand.
Related
We have a Web API secured with IdentityServer4 using local API authentication. We are currently using both Reference Tokens and Refresh Tokens. Since we have the ability to revoke a reference token at any time is it even necessary for us to use refresh tokens? Couldn't we just set a long expiry for the reference token? Is there any security implications to this approach?
From the documentation:
When using reference tokens - IdentityServer will store the contents
of the token in a data store and will only issue a unique identifier
for this token back to the client. The API receiving this reference
must then open a back-channel communication to IdentityServer to
validate the token.
In other words, the client doesn't have to provide an access token to the api, only pass the reference.
This is a big difference between the JWT token and the reference token. The client sends the API the JWT token that has to be trusted by the API without consulting the provider, while the reference token forces the API to contact the provider, not having to rely on the client.
From the Refresh Tokens documentation:
Since access tokens have finite lifetimes, refresh tokens allow
requesting new access tokens without user interaction.
The question now is, can a reference token expire? Not from itself, as it contains no logic, unlike the JWT token. But there may be a server side setting that triggers some kind of expiration, or actually cause the reference to be revoked.
Either way, there is no use for a refresh token in this scenario. As you can't refresh the reference token. The reference token either exists or not (is invalid or was revoked).
We are using OAuth to get Access Token and Refresh Token. But Access Token is getting expired fast.We need token with long validity.
How can we achieve this?
In Dynamics CRM, Access tokens are expired in 3600sec. But refresh token will not expire. So you need to generate the new
accesstoken using the refresh token.
If you want refer below page, It will useful for you.
https://learn.microsoft.com/en-us/previous-versions/azure/dn645542(v=azure.100)
I'm looking into Oauth2 to allow developers to authorize users of their app to use my service. I've found a few sources that say that my Authorization Server should return an access token when a user sends an assertion (JWT in my case) but that it should not return a refresh token. I'm wondering what the harm is in returning a refresh token. Developers could invalidate refresh/access tokens by calling an Api that invalidates any access granted from a particular JWT's id.
That recommendation is not correct. Refresh tokens are optional and can be issued at the discretion of the Authorization Server after client presents the authorization grant. See Oauth2 specification
1.5 Refresh tokens
Refresh tokens are credentials used to obtain access tokens. Refresh
tokens are issued to the client by the authorization server and are
used to obtain a new access token when the current access token
becomes invalid or expires, or to obtain additional access tokens
with identical or narrower scope (access tokens may have a shorter
lifetime and fewer permissions than authorized by the resource
owner). Issuing a refresh token is optional at the discretion of the
authorization server. If the authorization server issues a refresh
token, it is included when issuing an access token (i.e., step (D) in
Figure 1).
I am new to OAuth and was wondering why authorization code is required?
Why authorization does not send access token or refresh token in callback response.
why not directly access token?
The Authorization Code grant uses the short-lived one-time code so that it can be exchanged for the real token (which is longer-lived and multiple-use) in a backchannel call that is more secure and can leverage credentials to authenticate the Client towards the Authorization Server.
The Implicit grant type returns the access token directly in the authorization response. It is considered to be more insecure because it is easier to attack (using crafted redirects etc.) and because there's no way to keep a client credentials secret.
I am using Oauth to access Google Cloud Storage via their JSON API.
All is fine, I authenticate and get an access token which has an expiration of 3600.
What is the correct way to refresh this?
It is my understanding that in other types of oAuth flows (i.e. Web Server), the initial authorization request returns a refresh token as well as an access token, and that the refresh token is used to ask for another access token when the current access token has expired.
But is appears that there is no refresh token when doing server-to-server oAuth with a Google "Service Account"?
Found the answer.
https://developers.google.com/accounts/docs/OAuth2ServiceAccount#expiration
Access tokens issued by the Google OAuth 2.0 Authorization Server
expire one hour after they are issued. When an access token expires,
then the application should generate another JWT, sign it, and request
another access token.