According to https://groups.google.com/forum/#!forum/oauth2-dev discussion is now here.
No matter how much reading I do, I can't get my head around how google OAuth2 tokens work. Reading the docs and many other places suggest that a refresh_token doesn't expire, and is used once the access_token expires. See the official docs at https://developers.google.com/accounts/docs/OAuth2WebServer#refresh
However, in practice it appears to work as describe by Paul (Unable to refresh token after expiration) that the refresh token expires when the access token expires.
Can a Google Engineer please confirm what the correct behavior should be as this appears to be a case of behavior and documentation not matching.
It also makes the refresh token useless.
If you request access_type=offline when making the initial request to https://accounts.google.com/o/oauth2/auth then you'll get back a refresh token along with the access token. This is documented here.
The refresh token does not expire, until the user explicitly revokes access to it from the Account -> Security -> "Connected applications and sites" page.
The other post you linked to seems to be related to SoundCloud, which presumably does things a little differently.
Related
There seem to be no complete explanations of how to do this, or even enough fragments for me to piece together what I have to do. After about 16 hours of studying, I am at wit's end.
It seems like I can't use SSO, and I also can't use PKCE because there is no working example anywhere on the web. There is a github repo with an example implementation, but it does not function and after 2 hours playing with it I cannot determine what I need to do to move forward this way.
Thanks for any help.
You can add offline_access to your scope (e.g. "scope": "offline_access openid something:else",) and this will yield you a refresh_token.
Auth0 currently supports unlimited refresh_token usage, so when your access_token expires (you either can track expiration time manually using "expires_in": 86400 value in respones or react on 401 response from api) - you can send your refresh token to OAuth2 api endpoint and receive new access token back. They have few descent articles about this matter and what you need to configure for your clients and API as well as what not to do (depending on your client security assumptions).
Take a note - you must secure refresh_token properly - store it in some reliable store and prevent any external scripts from accessing it. I assume with electron app you can do it more reliable than with a public website.
We have an Instagram client id and client secret, and already have gone through the documentation of generating access tokens which requires redirect url.
Note that we also have disabled the implicit OAuth flow.
Now we already have generated the access token using URL below (for authenticated user, it returns the access token appended in the response URL)
https://api.instagram.com/oauth/authorize/?client_id={client_Id}&redirect_uri={redirect_url}&response_type=token&scope=public_content
Can this token be stored in the database / configuration files and re-used for any new Instagram API requests? e.g.
https://api.instagram.com/v1/users/{user_id}/media/recent/?access_token={reusable_access_token}
Based on the official documentation, we understand that the access token can become invalid at any point of time, we would like to know if there are any specific scenarios which leads to invalidation of the access token?
What would be the best way to generate token once and use it for each API request? We definitely do not want users to enter credentials manually to generate tokens.
Unfortunately at that point it's not possible:/ Instagram doesn't provide refreshing access token in the background.
User needs to login with their credentials, so you can obtain new access token. Some kind of workaround (not nice, but it's working) is to watch for error type OAuthAccessTokenException and notify the user via e-mail about such fact. He will have to login once more, so you can get fresh and working access token.
Also, please keep in mind that access tokens has a pretty long life span. It doesn't expire after a day or two, unless Instagram API has some issues (like just now OAuth - unable to exchange code to access token for some users).
Otherwise it works really well.
However it would be super nice if Instagram could add to their API renewal option in the background for access tokens for users that autorised your app, but their token expired:)
I have searched a lot but I can't find the right answer.
I'm working with the Spotify Web API. The access token is only valid for 1 hour. I want to know if it's possible to renew the Spotify access token automatically? And if the answer is yes, how can I do that?
Thanks
Better solution what was find is: Login use Authorization Code Flow
you will receive access_token and refresh_token - and when access_token expired you can get new use refresh_token as describe in '7. Requesting access token from refresh token'
I am building an integration component using a graphical framework who has a pre-build OAuth2 connector.
This framework required following fields for OAuth v2:
Grant type
Scope
Auth Server URL
Client Id
Client Secret
Access Token
Refresh token
I need to get data from Google Analytics API, so I went to Google Dev Console
(https://console.developers.google.com/project/927890000889/apiui/credential). I generated a 'Client ID for web application'. From the parameter of this object I was able to fill some of the parameters above
Grant type : 'authorisation_code'
Client Id : 'RANDOMCHARSam5o37nsiu730d.apps.googleusercontent.com'
Client Secret : 'RANDOMCHARSiSwBA5OH5qYLUa'
Then using Google Oauth Playground (https://developers.google.com/oauthplayground) I was able to fill the missing bits
Scope : 'https://www.googleapis.com/oauth/analytics'
Auth Server URL : 'https://accounts.google.com/o/oauth2/auth'
Access Token : 'RANDOMCHARSQAQv4HRF5-JsQEzUS61lj2YremyCocv0PQ4-agpzJe'
Refresh token : 'RANDOMCHARSLPJnL4FPaDc2KP6V8kCzjjHO2Kj4Np_3X0'
Everything works fine, I am authorised to access and I get data from Google Analytics, but just for a while, after few minutes if I retry I receive an authorisation failure error.
I believe that the problem is related to the expiration of the Access Token, but I don't know how to solve that.
Worth to mention that this activity it's batch (no human interaction), so nobody can request a new access token.
The integration framework is not extensible (I cannot write code to renew the code) so I believe there's a way to get a access token that never expire or some other mechanism to achieve the same result.
Bottom line, I am not sure if I approached the requirement correctly since the beginning (Client ID for web application).
Any help is much appreciated,
Giovanni
Access tokens typically expire after 60 minutes. If you have a refresh token you can use the refresh token to get a new (valid) access token.
This doc explains how to do that:
https://developers.google.com/accounts/docs/OAuth2WebServer#refresh
To answer your overarching question, yes, you are approaching everything correctly. All you need to do is handle the case where the access token has expired by refreshing it. Also, when you originally requested the access token the response should tell you how long it's valid for, so you should only refresh that token if it's expired.
You can use Refresh tokens to make it more long used.
The Google Auth server issued Refresh tokens never expire,
A token might stop working for one of these reasons:
The user has revoked access.
The token has not been used for six months.
The user changed passwords and the token contains Gmail scopes.
The user account has exceeded a certain number of token requests. There is currently a limit of 50 refresh tokens per user account
per client.If the limit is reached, creating a new token automatically invalidates the oldest token without warning.
This limit does not apply to service accounts.
from: https://developers.google.com/identity/protocols/OAuth2
I'm doing some research for work with a view to using Bearer tokens as an authentication mechanism (i.e. AngularJS UI, authenticates via OWIN in a Web API [2] project).
I have the login working fine, role information and all that is fine, but I cannot get the token to logout.
My startup configuration is this:
OAuthOptions = new OAuthAuthorizationServerOptions() {
TokenEndpointPath = new PathString("/Token"),
Provider = new ApplicationOAuthProvider(PublicClientId),
AccessTokenExpireTimeSpan = SESSION_TIMEOUT,
AllowInsecureHttp = true
};
And my logout action is simply this:
public HttpResponseMessage Logout() {
var authentication = HttpContext.Current.GetOwinContext().Authentication;
authentication.SignOut(DefaultAuthenticationTypes.ExternalBearer);
return new HttpResponseMessage(HttpStatusCode.OK);
}
I've left all the authentication stuff out for brevity, but to confirm I am using ExternalBearer when setting up the token.
In my UI I'm storing the token in local storage (no cookies are involved here, which is a deliberate design decision). So I have a logout button on my UI, the Logout action is hit and the code runs fine.
However if I subsequently hit the an action on the API which requires authorisation, the request still goes through (i.e. the user is still authenticated even though they should have been signed out.
Either I'm missing something really obvious (wouldn't be the first time ;-) or there's something more fundamental going on here - finally I'm pinging #leastprivilege as I know this is their area.
Any help or insight would be gratefully received.
Only thing I can think of is that the token is stateless on the server/API side and hence can't be expired or signed out.
If that is the case I guess I could either:
a) Add a refresh token which creates a new token that expires in the past - would this even work? - actually cancel that, it would issue a new token ... the old one would still be valid
b) Store the bearer token in the database and check each time, removing the token on logout (naturally salted, hashed, etc). However this is just bringing us back to having a stateful server.
c) I can (and will) be removing the token from local storage when someone explicitly logs out, however the token is still technically valid if a baddy can intercept the token. Naturally all the above will be over SSL anyway, which should inhibit the bad guys/girls.
d) Perhaps this is why lots of people are storing the Bearer token in a cookie (as a storage mechanism) so once you logout as least the cookie will be removed on the next refresh.
Sorry the above is a bit of a brain dump, just wanting to pre-empt any questions
Since OAuth is not an authentication protocol, there is no notion of signout. Delete the access token on the client - that's all you can do.
If you want to invalidate the token on the server side, add a unique id to it and keep track in your service - you would need to manually build something like that.
I have a beautiful solution here: http://www.nakov.com/blog/2014/12/22/webapi-owin-identity-custom-login-service/. It is custom user session implementation for Web API OAuth bearer token authorization based on OWIN and the standard ASP.NET Identity (Microsoft.AspNet.Identity.EntityFramework). It works as most people may expect:
Web API sessions die after 30 minutes of inactivity.
Session’s life is extended at each authorized HTTP request with additional 30 minutes.
Logout works correctly: after logout the bearer access_token becomes invalid (its is revoked).
Full working source code is available at GitHub: https://github.com/SoftUni/SPA-with-AngularJS/tree/master/Ads-REST-Services
This question has been here for ages (and answered too), but I only wanted to chime in my thoughts.
I would do similar to your (C) option, but use a shorter expiry on the bearer access token something like 10 or 20 minutes, so that when you have logged out and deleted the token on the client, although technically the token is still valid, the bad man will have only the remainder of the expiry time to play with your valid token.
In practice, I would use this together with a long-lived refresh token, so that I can get a new bearer token if it expires and want to continue interacting with the API resources, without having to authenticate again.
As long as I know the bearer token lives in the client side so I don't think that you need a server side "logout" function. Just remove the token from the client local storage should log you out.