So, i've got this response from google upon authentication:
{
"user": {
"id": "116807551237969746774",
"email": "123456#gmail.com",
"verified_email": true,
"name": "John Doe",
"given_name": "John",
"family_name": "Doe",
"picture": "https:\/\/lh3.googleusercontent.com\/-XdUIqdMkCWA\/AAAAAAAAAAI\/AAAAAAAAAAA\/4252ldubv5M\/photo.jpg",
"locale": "en"
},
"credentials": {
"access_token": "ya29.GlsSBIA_hMKZIDE_wqJAJS0vrHD_Wd2HfwRTTvLISv0i1uFICCqz4JdEZcL09mFFlGdt71D9pW80SLShHgyeSOZgnWcL5piL5m0jYo1TMU6o0fDLnqGAWm6BY-Wl",
"token_type": "Bearer",
"expires_in": 3600,
"refresh_token": "1\/az_TmhPRaYG5NDH6L9gBeNo6STOD9EbTt1VkkBmp3IQ",
"id_token": "eyJhbGciOiJSUzI1NiIsImtpZCI6IjBlNmExN2I2YjU4MGIzNTFmMGQ5YmEzMzY2YTU0Y2U1NmViOWIxN2UifQ.eyJhenAiOiIxMDAzMjk3NzQ4MDc1LWsxdml0OGMxMHJ1ZnM4cjZpYmZyYmxlZmJhamFoZmllLmFwcHMuZ29vZ2xldXNlcmNvbnRlbnQuY29tIiwiYXVkIjoiMTAwMzI5Nzc0ODA3NS1rMXZpdDhjMTBydWZzOHI2aWJmcmJsZWZiYWphaGZpZS5hcHBzLmdvb2dsZXVzZXJjb250ZW50LmNvbSIsInN1YiI6IjExNjgwNzU1MTIzNzk2OTc0Njc3NCIsImVtYWlsIjoiNzA0MzA2N0BnbWFpbC5jb20iLCJlbWFpbF84PIXpZmllZCI6dHJ1ZSwiYXRfaGFzaCI6IkdrOHFjMTdCcEVGVGZmWkpKbkh6NGciLCJpc3MiOiJodHRwczovL2FjY291bnRzLmdvb2dsZS5jb20iLCJpYXQiOjE0ODk4MTIxMzksImV4cCI6MTQ4OTgxNTczOSwibmFtZSI6IkFudG9uIEFsZWtzYW5kcm92IiwicGljdHVyZSI6Imh0dHBzOi8vbGg0Lmdvb2dsZXVzZXJjb250ZW50LmNvbS8tTEJuMTlWX1NEN3cvQUFBQUFBQUFBQUkvQUFBQUFBQUFBQUEvQUFvbXZWMTRMVFIycUgtOXJ5S2dScjIxd3A1Z1FZRGNmUS9zOTYtYy9waG90by5qcGciLCJnaXZlbl9uYW1lIjoiQW50b24iLCJmYW1pbHlfbmFtZSI6IkFsZWtzYW5kcm92IiwibG9jYWxlIjoiZW4ifQ.BHv5BP3ZsagvunfMzGLwmxkBdtoRocPa_PXdq2lrd4D9BoFGkK06eJVbNNbcPOFdAMba3V5lIIG_L499gIy3TTz_PIHBPi6DMSp6uyfkCwf2n-PspZtTbTRlUm5ZvRdAyPEEyLLkWllKkMsRk-Nwp3vhyOLnExzH7SXiEefU4kaXXCpjsHV3GvZ-yhrmNlicEY3TPLwI-tl_lydXTBXRRiPZBGWjHK75hqvQzUktC2Flimd7JnCLhF0FOS3yFKc5D11WPKMOO4YkIQDbBrKY64vyxQAd-Zb2KfvXZi6Dorq7IJF6sK2GAfI3edSaoMZBMa0-x2V7FuFIBLtTgGRnsw"
}
}
I haven't found documentation on what should i do with credentials part of this response? What should i use for user identification? What should be saved as token on client side (ios/android app) in order to revive the session? What does expires_in: 3600 means and what should i do about it? What does token_type: Bearer means and why do i need it? etc.
Thank you, #pinoyyid for clarifications!
The main thing i was looking for is this:
On server side get access_token property from credentials and verify it, using this url
https://www.googleapis.com/oauth2/v1/tokeninfo?access_token={your access_token}
Do whatever you want with the rest of the provided data.
Personally, i'll prefer to generate own token, save it on client side and use it to revive user's session (to verify his identity). Once token is lost for whatever reason, user just will go through the whole process again.
what should i do with credentials part of this response?
Rejoice, for you have done the hard part.
What should i use for user identification?
Anything you like, or nothing at all. It depends on your app's use case.
What should be saved as token on client side (ios/android app) in order to revive the session?
The Refresh Token. Note that "revive the session" is wrong terminology. In OAuth/REST, there are no sessions.
What does expires_in: 3600 means and what should i do about it?
It is saying that the Access Token will expire in 1 hour (3600 seconds). What you should do is use the Refresh Token to acquire a new Access Token by POSTing it as described https://developers.google.com/identity/protocols/OAuth2WebServer#offline
What does token_type: Bearer means?
It means the Access Token should be placed in an HTTP Authorization header whenever you try to access a Google API. Eg Authorization: "Bearer aaaaaaa" where aaaaaa is the Access Token.
and why do i need it?
To prove to Google that your app has been given permission to access a Google resource (eg. a file in Drive) by the owner of that resource.
Related
I am using Oauth2+JWT+Spring security in one of my project. When i hit /outh/token using username/password i am receiving access token in the response with other details like
{
"access_token": <token>,
"token_type": <type>,
"refresh_token": <refresh-token>,
"expires_in":<secs>,
"scope": <scope>,
"jti": <value>
}
Is it possible to customize this response like
{
data: {
"access_token": <token>,
"token_type": <type>,
"refresh_token": <refresh-token>,
"expires_in":<secs>,
"scope": <scope>,
"jti": <value>
},
details:{
//extra information
}
}
I'm confused, don't know how to ask more clearly: "what is the additional data you want to send?". Just give an explicit sample.
I'll answer guessing that this data is related to the authorized entity (the user when answering within authorization-code flow and the client within client-credentials flow): non standard data should be set as private-claims, inside the JWT itself and on token introspection endpoint.
How to add such private claims depends on your authorization-server. For spring-security one, this is done with an OAuth2TokenCustomizer. For Keycloak, you have to provide a "mapper", etc.
The client which received a payload like the one you show, will only send the access-token when issuing requests to resource-server(s). It is important that this token holds all of the data needed for resources access decisions. Some claims are specified by OAuth2, OpenID defines some more standard claims, and you are free to put whatever additional data in private claims (within the limits of the maximum token size).
Also, if your client needs to read claims, it should use ID token, not access-token (request openid scope when initiating OAuth2 flow). Access-token should be interpreted by resource-server only.
Steps.
1. GET https://<canvas-install-url>/login/oauth2/auth?client_id=XXX&response_type=code&redirect_uri=https://example.com/oauth_complete&state=YYY&scope=<value_1>%20<value_2>%20<value_n>
2. POST /login/oauth2/token [grant_type=authorization_code]
Response:
{
"access_token": "1/fFAGRNJru1FTz70BzhT3Zg",
"token_type": "Bearer",
"user": {"id":42, "name": "Jimi Hendrix"},
"refresh_token": "tIh2YBWGiC0GgGRglT9Ylwv2MnTvy8csfGyfK2PqZmkFYYqYZ0wui4tzI7uBwnN2",
"expires_in": 3600
}
3. POST /login/oauth2/token [grant_type=refresh_token]
Response:
{
"access_token": "new_1/fFAGRNJru1FTz70BzhT3Zg",
"token_type": "Bearer",
"user": {"id":42, "name": "Jimi Hendrix"},
"refresh_token": "tIh2YBWGiC0GgGRglT9Ylwv2MnTvy8csfGyfK2PqZmkFYYqYZ0wui4tzI7uBwnN2",
"expires_in": 3600
}
From step 2:
"access_token": "1/fFAGRNJru1FTz70BzhT3Zg" - using this token returns an invalid access token error
From step 3:
"access_token": "new_1/fFAGRNJru1FTz70BzhT3Zg_new" - works!
My question is,
Is this the expected behaviour?
or
Should the access token from step 2 be valid until it expires(3600s)?
No When you use the refresh token and refresh it will generate a new access token and attach to the refresh token. Old access tokens will no longer work after that.
Expires in is a maximum TTL of the access token after which refresh is compulsory but there is no minimum threshold for refreshing an access token.
(I wanted to respond to your comment in shazin's answer. But I have no reputation :( )
AFAIK The old access token is invalidated when the refresh token is used to get a new access token.
I briefly looked at the OAuth2 Spec but could not find anything saying that the old access token is invalidated when the refresh token is used. Perhaps because it is assumed the refresh token is only used when the access token is invalid.
Anyway perhaps these 2 references from the spec will help.
Refresh token
Refreshing an Access Token
I am setting a keycloack authentication server to allow authorized users to access a protected resource (OAuth2.0).
The access will be done from an embedded device that has certain restrictions. The main restriction is that the access and refresh tokens cannot be saved if they are longer than 256 characters.
While in The OAuth 2.0 Authorization Framework is silent about the token size, all the identity providers are free to decide about the token size. For example, Facebook's token is less than 256 bytes, the same for Google. But for keycloack, I get a token around 850 bytes! I have tried several encryption algorithms available in the admin console by I still get a large jwt token.
Decoding that jwt gives the following:
{
"jti": "d654564qsd-5fqsdf5-4qsdf-8b25qs-b556456",
"exp": 1556284611,
"nbf": 0,
"iat": 1556270211,
"iss": "http://myadress:myport/auth/realms/myrealm",
"aud": "myapp",
"sub": "45464-445645-4b45641e-456456-45645646",
"typ": "Bearer",
"azp": "myapp",
"auth_time": 1556269490,
"session_state": "cb95519c-0bf8-4b6b-94e4-a10d9000dbd2",
"acr": "0",
"allowed-origins": [],
"realm_access": {
"roles": [
"user"
]
},
"resource_access": {},
"scope": "readwrite"
}
I am actually not interested at all in the data in the tokens and I am not parsing it. I just need the token to be able to access the resource.
Hence, is there a way to reduce the size of the token to less than 256? if no, what is the best result I can get?
Thank you in advance
Also try to change signing algorithm. RSA256 ~354 symbols, ESA256 - 86 symbols, HS256 - 43 symbols. Could be configured using realm -> token -> default token algorithm or on client page
One aspect of the token size are the roles. If you don't need the roles to be in the token because you don't care about roles or you query the roles differently (eg. direct access via admin api), then use client scopes to remove the unnecessary roles. I know this may not be what u wanted to hear but it may help some people to get their token below 1 kB ;)
Tip: You don't need to create a 'Client Scope'. Its enough to enable specific Scope in the Client config tab and leave it empty: Keycloak Admin UI > Client > Tab: Scope > Disable: Full Scope Allowed
I'm building a web app and using OAuth2 to authenticate. For testing purposes, I would like to test what happens when the access token expires and the refresh token is needed to re-authenticate. Since the salesforce oauth token does not contain an "expiry date" parameter, how would i forcefully expire the salesforce access token.
This is what is returned when a token is requested.
{
"oauth_token": {
"access_token": "<access token>",
"id": "https://login.salesforce.com/id/00DG0000000imtwMAA/005G0000001CFgeIAG",
"id_token": "<id token>",
"instance_url": "https://na47.salesforce.com",
"issued_at": "1522400000",
"refresh_token": "<refresh token>",
"scope": [
"refresh_token",
"full"
],
"signature": "<signature>",
"token_type": "Bearer"
}
}
If you want to do it manually, you can go to Setup > Security Controls > Session Management, then select the session from the list and remove it. Alternatively, if you need to do it programmatically, you could query and delete these records, which are stored in the AuthSession object.
Once you've done that, your access token will be expired, and attempts to use it will produce:
[ {
"message" : "Session expired or invalid",
"errorCode" : "INVALID_SESSION_ID"
} ]
Your refresh token will still be valid though, and you can use it to request a new access token.
Our service has a Trello integration, and we use OAuth to authenticate and authorize users. However, we're seeing all of our calls to Trello fail until the service reauthenticates the user. This started with a call to https://api.trello.com/1/lists to post a card, which received a 401 response. Getting a new token (by effectively reauthenticating) solved the problem, so it's not a permissions issue.
This problem initially sounded like a token expiration issue (since expiration=never is evidently supported), but it hasn't happened in the past and we've been using Trello's API for well over a year. Does anyone happen to know Trello's default OAuth token expiration and whether this has changed recently?
Thanks!
If an expiration is not provided in the request, the default value for the OAuth1.0 flow is 30days.
401s can also be caused by a user revoking a Trello token from their accounts page: https://trello.com/my/account.
Additionally, you can check the expiration date of a token via the 1/tokens route: https://trello.com/1/tokens/{tokenValue}?key={TrelloAPIKey}&token={tokenValue}.
An example response to that route looks like this:
{
"id": "a58541ff795dc3d9a124374b",
"identifier": "My Trello Token",
"idMember": "5859bd30f6582fbf01f4a8fc",
"dateCreated": "2016-12-16T16:45:06.810Z",
"dateExpires": null,
"permissions": [
{
"idModel": "69bdfbf01f58582530f4a8fc",
"modelType": "Member",
"read": true,
"write": true
},
{
"idModel": "*",
"modelType": "Board",
"read": true,
"write": true
},
{
"idModel": "*",
"modelType": "Organization",
"read": true,
"write": true
}
]
}
A Trello access token by default never expires. You can check this here:
https://trello.com/{username}/account
Under the 'Applications' section, you will find details of the API tokens associated with your account.