I am developing a Google action and added account linking
In the linked image you can see the settings I did in Action console->Account linking.
Action console Account linking
In AuthO Applications added all fields necessary, JWT Expiration set to 604800 also in APIs setting I have updated Token Expiration (Seconds) to Token Expiration (Seconds)
Auth0 application setting
Auth0 api settings
Account linking works perfectly but after 24 hours, my Google action prompts the user to ‘link the account again’, Even though I changed the JWT expiration to 7 days(604800 seconds) and Token Expiration to 7 days, I don’t know why action asks the user to link there account again after 24 hours. Is there anything I left out.
Kindly help me in this regard as it is very important me to publish action and running over my deadline
While the Assistant not accepting the long Access Token, the stranger thing is that it should be using a Refresh Token to get a new Access Token instead of requiring the user to re-link the accounts.
Assuming you're using the auth token flow (and it looks like you are), Auth0 will send a Refresh Token if you request the offline_access scope.
It looks like you're requesting _offlineaccess, which isn't the right scope. Changing this to the correct string (or adding it) should give the Assistant a Refresh Token, so it won't re-prompt the user unless the token is revoked.
Related
Case Scenario :
Suppose a user logs into a third party website using google Oauth. By default the google access token has the expiry time of about 3600 seconds.
If , after logging into the third party website
User deletes/inactivates the gmail account.
User removes the consent given to the third party app in gmail.
In the above cases does the access token get expired ?
In the above cases does the refresh token get expired?
Does the below link give the actual information about the access token in any one the above scenario.
https://www.googleapis.com/oauth2/v3/tokeninfo?access_token=
Suppose a user logs into a third party website using google Oauth.
Oauth2 is not for sign in (authencation) it is for authorization. So a user would not login to a third party website using oauth2 they would login to a third party website using their google account and open id connect.
By default the google access token has the expiry time of about 3600 seconds.
Industry standard for Oauth2 stats that an access token would expire after an hour or 3600 seconds.
In the above cases does the access token get expired ?
No access tokens are self contained bearer tokens. They will work until they expire in this case an hour. There is no additional validation on them it is assumed that the bearer of said token has access to the data for an hour. Yes even if they delete the access.
In the above cases does the refresh token get expired?
if the user revokes your access via their google account. All outstanding refresh tokens are removed immediately they will no longer work.
Does the below link give the actual information about the access token in any one the above scenario.
The UserInfo endpoint (is a standard endpoint) which can be used to retrieve identity information about a user who has authorized the application.
information returned can vary by server but it is most often. Username, profile name, can contain email address and birthdate.
The end point will return the info as long as the access token has not expired.
I'm following this article to understand refesh tokens.
In my case I have to connect to REST api using grant_type=password, and I receive a token with a 5 minute lifespan. So every 5 minutes I have to issue a POST request passing client-id, username & password to get a new acces token.
The other option would be to issue a POST with a grant_type=refresh_token, without having to send the username & password. In my case I'm consuming an api, so passing the credentials doesn't involve any action from the final user. For me it's just to params more to send on the POST request.
In both cases, I have to issue a new post every 5 minutes.
Is that the only advantage (not needing to pass credentials again) of using the reresh token or is there any other thing I'm missing?
Background info
OAuth 2.0 Password Grant
The Password grant type is a way to exchange a user's credentials for an access token. Because the client application has to collect the user's password and send it to the authorization server, it is not recommended that this grant be used at all anymore.
OAuth 2.0 Refresh Token
The Refresh Token grant type is used by clients to exchange a refresh token for an access token when the access token has expired.
This allows clients to continue to have a valid access token without further interaction with the user.
Consider this.
Lets say that i add my login and password for my twitter account to your application and you then use that to request access from twitter to may account to post. Three months later i have forgotten i have set your awesome app up to do something on my twitter account and i change my password. Your system will break.
Now lets say i used Oauth2 to grant you access to my Google drive account, your awesome app can now do what ever it needs to do on my drive account. Now three months latter i have again forgotten i gave your awesome app access, I have the memory of a gold fish you see. I change my password. Nothing happens your awesome app still has access.
Now consider this, With oauth2 i can grant you access to only read from my google drive account not update it (scope). That and the system knows its not actually me preforming the actions.
With client login (login and password) most of the time it appears to the system that it is the actually owner of the account making the requests. You can also not limit access with client login for the most part you have full access.
note
yes i am ignoring the part about both tokens returned being the expiration time time. Thats because for all intensive purposes they are the same but that depends greatly on how the auth server you are using is set up. They could be set up to only be valid for an hour or a day. They may give you different access scopes, again this differs greatly from auth server to auth server.
I'm developing an Android app that uses Outlook Calendar REST API. I'm trying to keep in synch and updated the calendars of multiple users (meeting rooms).
My questions are:
1) After how long does the initial authorization code expires?
2) And for the refresh token instead?
The access token expires after 60 mins. I can't get if for the refresh token expires after 6 hours, 14 days or 90 days.
3) Is the latter configurable? Can I make it not expire?
`
UPDATE: (from https://msdn.microsoft.com/en-us/library/azure/dn645542.aspx)
"The lifetime of the refresh token is not provided and varies based on policy settings and the time when the authorization code grant is revoked by Azure AD. The application should expect and handle cases when the request for a new access token fails. In that case, it should return to the code that requests a new access token."
And also: (from http://blogs.msdn.com/b/exchangedev/archive/2014/03/25/using-oauth2-to-access-calendar-contact-and-mail-api-in-exchange-online-in-office-365.aspx)
"Refresh tokens do not have specified lifetimes. Typically, the lifetimes of refresh tokens are relatively long. However, in some cases, refresh tokens expire, are revoked, or lack sufficient privileges for the desired action. The client application needs to expect and handle errors returned by the token issuance endpoint correctly. When you receive a response with a refresh token error, discard the current refresh token and request a new authorization code or access token. In particular, when using a refresh token in the Authorization Code Grant flow, if you receive a response with the interaction_required or invalid_grant error codes, discard the refresh token and request a new authorization code."
So how can I guarantee that my App will always have all the users logged in?
It will be in airplane mode during the night and it should automatically recover from crashes as well.
Can I solve without authenticating the users programmatically storing the credentials?
Thanks
Answers:
few minutes. The exact value is an implementation detail and can change at any moment. You should do whatever you can to redeem the code as soon as you get it.
see http://www.cloudidentity.com/blog/2015/03/20/azure-ad-token-lifetime/
as of today the lifetime limits cannot be changed. We are working on features that will grant you more control, but we have no ETA to share at the moment
The only way of guaranteeing that a user is signed in is to successfully redeem a refresh token, or to go through an authentication flow. Use of cached credentials is restricted to very few cases, and will likely be disallowed in upcoming versions of the service.
If a refresh token expires, you should plan to perform an interactive authentication. Note that the refresh token might also be invalidated by a consent revocation, which will mandate interactivity in all cases.
What you can do is to obtain the refresh_token and the access_token. Access what you need via the access_token, if that fails then assume it has expired and use the refresh_token to update the access_token. If a user changes their password (or maybe there are other cases) then you start the user over from square one.
To get the refresh_token I think you need to add offline_access to your scope. Something like this:
USER_OAUTH2_AUTHORIZE_URL
+ "?client_id=" + config.getClientId()
+ "&redirect_uri=" + getOutlookLoginRedirect(request)
+ "&response_type=code"
+ "&scope=https%3A%2F%2Foutlook.office.com%2Fmail.send%20" +
"https%3A%2F%2Foutlook.office.com%2Fmail.readwrite%20" +
"offline_access%20openid%20email%20profile"
I have a website where people can post blogs. I want the blogs to be automaticly posted to a Linkedin account connected to the website. So the person posting the blog is not the owner of the linkedin account.
I use the Sharing API from LinkedIN to do this, but this requires the administrator of the linkedin account to refresh the Oauth token every 60 days. I know this is a security thing to prevent illegal use of accounts. But in this case its always my own linkedIN account. Is there a way around this? mabe by using the app key and secret instead of the acces token?
The LinkedIn API docs (https://developer.linkedin.com/documents/handling-errors-invalid-tokens) say:
In the case the access token is already expired, your application will
go through the same authorization flow as previously described.
However, the login dialog will be shown to the user as they will need
to grant access to your application again.
so there's no way around that. But what you could do is go through this flow before the access token has expired. The docs say:
Simply have your application go through the authorization flow in
order to fetch a new access token with an additional 60 day life span.
When the following conditions exist:
User is still logged into Linkedin.com The current access token isn't
expired (within the 60 life span) We will automatically redirect the
user back to your redirect_uri without requiring them to reauthorize
your application. If they don't exist, we'll prompt them to login and
then redirect them.
I'm using the Doorkeeper gem to provide OAuth in a Rails app. The client is a Chrome extension.
I have 'use_refresh_token' commented out in doorkeeper.rb, and 'access_token_expires_in' set to 1 minute. I thought that would force the client to re-auth after a minute. But re-auth is happening automatically, regardless of whether use_refresh_token is present or not.
With use_refresh_token present, a new row is added to 'oauth_access_tokens' every time the access token expires. No new row is added to 'oauth_access_grants.'
With use_refresh_token commented out new rows are added to both tables. Which I would expect if the client was manually re-authing. But it appears to be happening automatically--the user is granted access without having to re-auth the app through the OAuth login screen, as I'd like.
Apologies for my ignorance, I'm new to both Doorkeeper and OAuth and haven't found any clues on Google et al.
The OAuth 2.0 is working as it is sending authorization URI to authorize url to get the access token and while the user is not authorized to get token the server redirect him to login page, I think the point in your case that the expire in time is too short so the session opened when user entered username and password for first time still valid so when your client asking for new token it is getting it as the user is still loged in on the authorization server, you can change the time of session to be less than the token validity time and test it.