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
Related
I am trying to integrate the Google sign in sdk into my site.
I have already added the GSI button to my site and on clicking it, google sends the IDtoken containing the user info to my oauth endpoint.
Using this token, I can now create a new user account.
So far so good.But I am not sure what I am to do from here.
Should I put this IDtoken into a http_only and secure, cookie so that all authz server requests will contain the userid?
I am seeing lots of cookie and local storage based data has been been added to my sites jar. Am I supposed to use them in any way?
What do I need to do after the token expires after 1 hr? Do I need to have my users login yet again? I did not get any refresh token along with the idtoken. Do I even need to handle the refresh token or is the gsi sdk supposed to take care of all that for me?
Another part which is not clear is what do I get from using the Google sign in button/sdk vs the general Oauth-openid flow.
I'm trying to set up Google OAuth2.0 from this guide and I have everything set up and running. I can get the authorization code, the access_token, and the refresh_token to show up in my console.log's. My question is which one of these tokens can I use to properly identify and log in a user to my backend?
In a normal scenario, a user would enter a username & password and that would uniquely identify them. However in the Google OAuth2.0 case, it seems the authorization code, the access_token, and the refresh_token all cannot be used to properly identify and log someone in. Is this understanding correct?
I read a similar post but it doesn't seem to provide a very recent answer that also securely identifies the logged in user.
If I cannot use any of the above mentioned tokens to securely identify and log in a user, is it even possible? How come I see other websites and apps use "sign in with Google" and "sign in with Facebook"?
Another solution I read in a different StackOverflow post said to just get the account ID and use that as an identifier. Isn't that insecure? Can't someone guess the account ID? Also this would be assuming these account IDs are private.
My question is which one of these tokens can I use to properly identify and log in a user to my backend?
the id token from open id connect.
explanation
You are confusing authorization and authentication.
Oauth2 a user to grant and authorize your application access to their data the access token gives you access to their data for a limited time (1 hour). If the user is off line you can use the refresh token to request a new access token. None of theses will tell you that a user is behind the calls.
open id connect allows you to authenticate a user logging in will return an id token
Id token verification
After you receive the ID token by HTTPS POST, you must verify the integrity of the token. Verify the integrity of the ID token
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'm trying to acquire a 2 legged oauth2 access token for google's storage api through a service account.
The relevant documentation is contained here:
https://developers.google.com/identity/protocols/OAuth2ServiceAccount
I first tried attempted to acquire the token through their HTTP/REST api. I eventually gave up being unable to get past a 400 response with the following details:
{ "error" : "invalid_grant" }
I then turned to the recommended method: using the java Google api client library (I'm using scala).
val credentialBuilder = new GoogleCredential.Builder()
.setTransport(GoogleNetHttpTransport.newTrustedTransport())
.setJsonFactory(JacksonFactory.getDefaultInstance())
.setServiceAccountId(Configuration.GoogleAPI.ServiceAccount.email)
.setServiceAccountPrivateKeyFromP12File(new File(Configuration.GoogleAPI.ServiceAccount.pkcs12))
.setServiceAccountScopes(Collections.singleton(StorageScopes.DEVSTORAGE_FULL_CONTROL))
def updateToken = {
val credential = credentialBuilder.build()
credential.refreshToken()
// ... do stuff here with token
}
Running the above, I get a TokenResponseException, with a payload identical to the error I was getting directly accessing the REST api. 400 Bad Request, invalid_grant error.
Doing some research (on both stackoverflow and elsewhere), I find that the most common reasons for this error message are:
1) The local clock is not synced with Google's servers. I suspected this even back when I was using the REST api because I've encountered this issue for other services before. I'm fairly sure its not a clock issue however, because I have repeatedly synced my clocks with an external ntp server:
sudo ntpdate -s ntp.ubuntu.com
2) The other common cause for this error is setting the service account client ID incorrectly. Most people set it to their service account client id (ending with "apps.googleusercontent.com") instead of their service account client email. Its pretty clear that this isn't the problem, since I'm correctly pointing to the email (the docs instructed this, so I followed the directions), ending with "#developer.gserviceaccount.com".
I'm stuck. I've checked the user documentation, the javadocs, various forums. The error message isn't very helpful (probably designed that way, since it's a security endpoint).
What other possible causes for this error exist? What can I do to get my service account access token?
If you are using OAuth2.0 to access a google analytics account then there could be one more reason of getting invalid_grant. As per developer docs:
If the application attempts to use an invalidated refresh token, an
invalid_grant error response is returned. The limit for each unique
pair of OAuth 2.0 client and Google Analytics account is 25 refresh
tokens (note that this limit is subject to change). If the application
continues to request refresh tokens for the same Client/Account pair,
once the 26th token is issued, the 1st refresh token that was
previously issued will become invalid. The 27th requested refresh
token would invalidate the 2nd previously issued token and so on.
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.