I am working on Vimeo API for a video streaming service and I have understood pretty much everything from the documentation.
My main concern is that I have not encountered any documentations on access token expiry.
So, can the access token expire once generated? If yes then after how long? And can one refresh the token after expiry using the APIs?
Thanks.
It actually is documented here:
https://developer.vimeo.com/api/authentication
But in general I will say I've had nothing but trouble with the Vimeo API and absolutely detest their support and service. For a company pumping millions into advertising, their services kind of suck.
NOTE: Expiration times for access tokens vary, depending on the type of the token and the way that the token is granted. Some access tokens have a limited lifespan. Others continue to work indefinitely, as long as you use them on a regular basis. To keep things running smoothly on our end, we automatically delete any tokens that appear to be inactive. For more information, see the descriptions of the individual authentication workflows below.
I will just go ahead and answer my own question. After more reading I found out that the vimeo access token never expire. This is not documented though.
Related
Is there a standard mechanism in Open ID Connect to kill an active session?
Say a client has an Access token set to expire in 2 minutes. Someone from a central location logs the user out. The idea to prevent that access token from being viable on the very next request as opposed to when the token expires.
This would require Web APIs to contact the authorization server on every single request, which would cause performance problems.
It is standard to use short lived access tokens as the best middle ground. Most commonly this is around 30 or 60 minutes by default.
When reviewing OAuth behaviour in areas like this it can be worth comparing to older systems:
It was never possible to revoke cookies in the manner you describe - so security is not made worse by using OAuth 2.0 based solutions
Typically it is possible to centrally revoke refresh tokens though, so that the next token refresh requires a new login.
There are a couple of drafts that are helpful depending on your specific implementation:
https://openid.net/specs/openid-connect-session-1_0.html
https://openid.net/specs/openid-connect-backchannel-1_0.html
https://openid.net/specs/openid-connect-frontchannel-1_0.html
Several OIDC products are using these methods currently:
https://backstage.forgerock.com/docs/am/6/oidc1-guide/#openam-openid-session-management
https://www.ibm.com/support/knowledgecenter/SSD28V_liberty/com.ibm.websphere.wlp.core.doc/ae/twlp_oidc_session_mgmt_endpoint.html
Several Others also.
I'm working today on a partner environment related to Google Home.
Concretely, when I use google home to give orders on devices, Google calls my API to execute them (as it does with Philips Hue, Netatmo etc ...).
My problem is this: I use keycloak for OAuth management. the Google console has been configured to use it and it works. However my refresh_token expire and this forces the user to delete the linked account and then postpone it.
My question is this: Does Google expect to get an infinite refresh_token after giving its authorization_code? Or I missed something, because Google does not seem to restart the normal connection procedure.
Keycloak 3.2, Google homegraph action-on-google
Typically, yes, Google assumes the refresh_token has either no expiration or an extremely long expiration period. But it does acknowledge that the refresh_token can either expire or be revoked. In that case, you need to make sure your OAuth server returns HTTP code 400 with the OAuth error invalid_grant.
I personnaly consider a good practice to revoke refresh tokens after an period of inactivity.
This gives a pretty good user experience while keeping the database updated.
I'm not sure if this is just exclusive to google API's and this is not plausible, but in the OAuth google developers playground, one can give in an access token and receive a refresh token which never expires. I for one have done this and implemented it in my code, but I was wondering, is there such a thing for an Instagram access token?
With the recent changes taking place in there api (2016 ->), I have not found any questions asking this as before I believe the token did not expire.
Thank you and sorry if I seem to be missing something obvious.
From the doc:
Access tokens may expire at any time in the future.
Even though our access tokens do not specify an expiration time, your app should handle the case that either the user revokes access, or Instagram expires the token after some period of time.
So in short, today, tokens do not expire, but they could in the future, so your app must handle the case if one day they expire.
I am implementing an App Store for my application where third-party developers can build there own apps based on my API. I have everything working and understand the concepts of OAuth 2.0, but I don't see how an external app can have timeless access with an access code that expires after one hour. Now you can use a refresh token to request a new one, but that one expires after some time too.
So how can an external app continuously connect to my API when the user of that app allows it only once?
My authorization codes expire after 10 minutes, the access tokens after 1 hour and the refresh tokens after 2 weeks.
I don't see how the app can retrieve data after those periods of time without the user re-allowing/re-installing the application through oauth.
How are bigger companies like Facebook etc. approaching this? Do they have an access token that never expires?
Expanding on my comment, the general recommendation when using bearer tokens is that their lifetime should be reduced in order to mitigate the impact of an access token being compromised.
On the other hand, asking the user credentials every hour or so would be an UX nightmare so OAuth 2.0 has the notion of refresh tokens which will normally have a longer lifetime allowing the application to request a new access token without requiring user intervention.
I'm unfamiliar with the implementation details around Facebook persistent tokens so I won't comment on that, but they are most likely safe. However, you're not Facebook, so my recommendation would be for you to follow public standards like OAuth 2.0/OpenID Connect instead of trying to provide a customized approach.
Regarding your comment about refresh tokens that never expire, it's an acceptable solution, but their lifetime is just one part of the equation. You should consider if they are multi-use or single-use, they can only be used by the client application that they were issued to, they should not be used by browser-based applications due to the difficulties of ensuring secure storage, etc.
I am trying to figure out how an access token in OAuth 2.0 should be used. To be more precise, I am trying to use the Google Plus API from a web application.
I am now able to get a code and from it an access token. The problem is that this token is only about 3600 seconds valid.
Is there a way to get another token without making the user go again through this process: https://developers.google.com/accounts/images/consent1.png because it seems a bit irritating. I know of the offline access and its refresh token, but it doesn't feel right to have permanent access to a user's account.
Do you have any ideas on how should I proceed?
I'm definitely not an authority, but I believe the answer is 'no'. The offline token allows you access without subsequent user approval, but only to the scopes to which the user already agreed when authenticating for the first time. Also, the user has the option of revoking your application's access at any time, which when combined with their previous consent means they both a.) know what they're allowing; and b.) can stop it at any time. Ostensibly, if a user uses your app enough that they constantly have to get a new token, they already trust it to act on their behalf within the scope you set, and the offline token is a way for you to take your relationship to the next level :)
I realize this is probably more philosophical than you were looking for, so apologies if it isn't pertinent to your situation.