Question says it all. I couldn't find anywhere in the API that states what happens when it expires. Do you have to open that "Works with Nest" webpage again and get a new authorization code? Or, using the same authorization code, just get a new token? And how will Nest indicate the token has expired?
Expiration date comes back in the OAuth response and is set to 10 years in the future, which is practically forever. That gives Nest quite a few years to come up with a refresh or expiration story.
Related
I have a question on "make the browser send out a request to exchange for a new token at the sixth day. Accordingly, on the server side, create a restful API named /token/extend which will return a new token if given a valid token."
Let's assume that I implement this concept. When token is about to expire, we will generate new valid token if old valid token is provided.
Now, let's assume, Hacker gets the token. He uses this token to communicate with APIs. Hacker communicates for 6 days. On 6th day, our "/token/extend" API will generate new token for him so he can communicate for another 6 days, and probably forever. Will this situation occur? or Am I missing something here?
The general way you would force your users to obtain a new token after 6 days would be by simply setting the exp field (expiry) in the claims of the JWT to expire after 6 days. The exact mechanism by which users would use to obtain a new token depends on your implementation.
The most basic implementation would be to just let the incoming request on the sixth day to fail, forcing the consumer of the API to redirect to the login page. From there, the user would have to login again to obtain a new valid JWT. A more elaborate method would use refresh tokens. With this approach, when the user first logs in, he would receive an authentication token with a 6 day expiry (as before), but would also receive a refresh token which would expire a little bit later. On the sixth day, when the user tries to access a service, the request would again fail. However, in this case, the consumer (e.g. a website or mobile app) could take the refresh token and request a new access token under the hood. This would be a more seamless way of handling the mandatory 6 day expiry. Note that with the refresh token approach, the user might never know about the 6 day expiry.
Regarding your concerns about hackers obtaining other people's tokens, you should mostly just forget about this. If someone stole your wallet, there is all sort of havoc he could do to you, e.g. using your credit cards, stealing your identity, etc. The same could happen with a stolen/sniffed JWT. The best practice here is to just make sure you are using two-way SSL for all communication, and also encourage your users not to use your services in places like Internet cafes.
This question already has answers here:
OAuth2.0 Server stack how to use state to prevent CSRF? for draft2.0 v20
(3 answers)
Closed 5 years ago.
I've implemented Google OAuth2 login for different Google services a couple times now, but never really thought about how the state token can be abused if no session token is included.
I understand the principles of CSRF and I've implemented my OAuth2 flows as described in https://developers.google.com/accounts/docs/OAuth2Login (with session token in the state token), I just don't see how an attacker can abuse this if the session token is not present.
Maybe it's related to what I do after a successful response from the Google consent page (I obtain refresh + access token, store them to a user specified in the state token and redirect to another page also specified in the state token), but how is it a problem otherwise?
I saw this answer in a related question, which explains how a CSRF attack can be done (and how the state token prevents it): https://stackoverflow.com/a/23640462/736247
Just read about the offline_access permission being removed and therefore having the new system of "extended access tokens".
My problem is that i'd like to save the expiration timestamp to take care that the saved access tokens are always valid, but the Documentation doesn't provide a time that the extended token is valid for.
Does anyone have more information regarding that?
It'd be interesting to know if they long-living tokens are valid for days, weeks or months.
When you use the new endpoint which is explained in the post you linked to:
https://graph.facebook.com/oauth/access_token?
client_id=APP_ID&
client_secret=APP_SECRET&
grant_type=fb_exchange_token&
fb_exchange_token=EXISTING_ACCESS_TOKEN
The response will have this form:
access_token=xxxxx&expires=yyyyy
The expires param is what you are after I believe.
Long lived tokens are good for 60 days, and you can check tokens (for debugging) with the Debug Tool which will tell you everything you need to know about the token.
Edit
A few more things.
The "expires" parameter gives you the time left until expiration, so the expiration time is timestamp of now + expires.
It's easy to check this with out the need to do any development, just create a fb app (if you don't have one), go to the Access Token Tool and copy the user token from your app, then using curl make a request to the new endpoint.
As for extending the long lived tokens, there's no way to do that, you'll need to re-authenticate the user after that, as it states in the same post:
If you pass an access_token that had a long-lived expiration time, the
endpoint will simply pass that same access_token back to you without
altering or extending the expiration time
Another point is that you can get long lived access tokens by using the Server-Side authentication flow, but those too can not be extended.
It only returns back access_token not
access_token=xxxxx&expires=yyyyy as mentioned above.
Atleast that is what I can see...
I ask for a Facebook access token with deprecate_offline_access turned on, and I get following response:
access_token=XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX&expires=5183977
Does anybody know, what "expires" parameter means? It's value is not timestamp...
I would like to know when the token expires, how could I do this?
Thank you.
The "expires" parameter is just the time remaining from the time of request until the expiration time. It should be read as "expires in 5183977 seconds from time of request".
5183977 seconds = 59.9997337962963 Days.
and answer to your last question 'what will I get if token is expired? will I get exception or just expired=0?'
you will get notification before token expire. If it is already expired (for mainly different reasons explained in facebook developer documentation) you have to re0auth the app and have to get new access token which will be again valid for next 60 days.
I am working with Oauth2.0. In that i could able get the access_token and instance_url. Is there any expiry time for these two.
Can I store them and use it for all my REST calls without getting the new access_token and the instance_url. Is it possible for me to use it for long hours or even days.
The access token is only valid for the length of a session (as defined in the Salesforce Org's settings — I believe the longest this can be is 8 hours without activity), as it's actually a session ID, that said, you should also be given a refresh token. The refresh token has a much longer lifetime and can be used to authenticate the user once the session has expired, without them having to enter any credentials — this allows you to do it in the background without them even having to concern themselves with the login process.
model metrics do a good job of explaining the token flow here.