I am using gapi.auth2.authorize to authorize people in my Google Photos API app but I cannont find a why to unauthorize or disconnect them from the app. What I have noticed though is that there is no way of using an old access token so that the user doesn't need to authorize.
How can I make the access token invalid?
Is it correct that every time the API is used the user has to authorize?
Thanks
How can I make the access token invalid?
Not possible to invalidate an access token, it will expire after 1h
You can check documenttation here
Is it correct that every time the API is used the user has to authorize?
Nope, you should ask users to authorize only once, using a refresh token that you can keep in your back-end, thus allowing your app to content on on users behalf all the time, until they revoke permissions
Related
Current situation
We have a very common system architecture with Spring Boot back-end and Angular front-end. For the mobile app we use Ionic, which basically uses same codebase as the front-end but adds additional features like biometrics etc.
User login is based on OAuth and access and refresh tokens are created once the user initiates the session. The access token has a short life span, where the refresh token is valid for a couple of days. As I said - very common auth flow.
What we want to achieve
Mobile app users should be able to login only once and then use the
app without the need to re-login every time the refresh token
expires.
For the "normal" front-end app refresh token expiration
policy should stay unchanged, meaning the user is forced to log in
again once the refresh token expires.
Possible solutions (from my perspective)
we pass an additional param to the login request specifying the client: web | mobile. If client is mobile refresh token validity is extended to expire in 1-2 years. Downside: this will break the whole idea of having tokens, that expire. I personally see this as a security issue.
we store credentials on mobile app local storage. Once we have session expiration, the app uses the credentials to re-authenticate. Downside: again I don't think this is a good idea having credentials stored on any device makes the flow vulnerable.
What I am looking for is kind of a best practice to solve this.
You are right, It's a security risk to have tokens that never expire or expire in a few years but they are used. Anyway, one thing you could do is to add a field in the refresh token endpoint that when you set it to true (defaults to false) it would also extend the lifespan of the refresh token. And you could periodically call that endpoint from your app. It should work even when It's in the background.
Or
If you wanna store the credentials in the local storage at least store them encrypted. You might need to create an endpoint that encrypts them because you should not have the private key in the mobile app. Then you'll probably need to create a custom authentication method that takes the encrypted credentials and compares them with the ones in the database.
In our service, we offer Google Sign-In alongside email/password sign in, and need to know when a user loses access to their Google account so we can disable an integration.
Without forcing the user to re-authenticate with Google Sign-In, how can we detect when they lose access to their connected Google account?
The approach that I am thinking through my search is
obtain access_token and refresh_token through OAuth 2.0 authentication when user signs in on our service with Google Sign-In, save them in our database
periodically, make request to https://www.googleapis.com/oauth2/v3/userinfo using saved access_token (we will get an error if user's google account is closed)
if access_token is expired, retrieve another one using refresh_token, then re-try step 2
Is this the right approach or is there a better way to achieve what we want?
Google OAuth 2.0 Tokens expire in 3,600 seconds. They are valid until they are revoked or expired.
When you request the access token, make note of the expiration time in your database and consider the token valid until expiration.
The other option is to continue validating the access token on every request which takes more time than it is usually worth.
Google does not have a callback mechanism to notify you of expiration or revoking of a token.
I am using this googleapis nodejs client for calendar, and everything works perfect except that if I remove access from google account security settings,
calendar is still connected. Is there any method to check for removed access from google account? How to handle those cases?
When a user runs your application the first time they are presented with a consent form. Which asks them to grant permission for your application to access their Google calendar data. From this point on when ever your application runs the user may have to login again but they will not have to grant your application permission. If you have a refresh token you will be able to use that when ever you like to request a new access token. the access token will be valid for one hour.
Now if you request a new access Token as stated its valid for one hour. This is true even if the user goes to Google Account security for their account and removes the consent for an application access their data.
Your still going to be able to access their data while any access tokens you have currently are valid. If the user tries to use your application again they will have to consent permission. If you try to use the refresh token it will no longer work.
Access tokens work for one hour they are not reauthorized during that time its assumed that they are valid. (This may in fact depend upon the scope and API in question and how googles policy server works.)
access token are designed to be self contained permission systems. As long as you have an access token for the correct scope most apis assume that you have access. However in the event this method is accessing critical data then they may have a policy server setup. This server could be doing an extra check on an access token to ensure that the user still has access even though they have a valid access token. However doing this can be very time consuming and resource heavy as reevaluating every call to ensure that the user still has access. It kind of defeats the purpose of having access tokens that are valid for an hour in the first place.
I'm developing a mobile app which will allow users to browse without signing up. I would like to have all my endpoints secured via token.
How would we go about allowing anonymous browsing? i.e. provide a token to anonymous users.
Not sure to understand your case, why do you need a token if your users aren't registered and your API opens to everyone?
The authentication system of Strapi has been built to only send token to registered users. However, the easiest way to make it work for you is to register every visitor coming in your app based on their IP or something unique as a username and set the same password for each one of them. Then, every time the user comes back, you can call the /auth/local URL to sign-in the user and get the token or use the token stored in the local storage.
GET https://www.yammer.com/dialog/oauth?client_id=[:client_id]&redirect_uri=[:redirect_uri]&response_type=token
Above request returns access token but I don't know how does it expire so I want to have a "refreshing" method when user is not logged on.
GET oauth2/authorize?client_id=[:client_id]&response_type=code&redirect_uri=[:redirect_uri]
POST oauth2/access_token
client_id=[:client_id]&client_secret=[:client_secret]&code=[:code]&grant_type=authorization_code
It requires user already logged into Yammer.
Is there a way to get access token (user is not logged in) by registered app (client_id & client_secret) or something like that?
Thank you!
Is there a way to get access token (user is not logged in)...
A user must be logged-in to able to generate an access token.
You'd be happy to know that tokens generated this way are long lived. They hardly expire unless the user revokes the app's access, or the app and/or the owner is disabled/deleted. So you really do not need a refresher token service. Once you obtain the token, you may want to save it a safe location/DB and re-use it for as many times as you like. Although it's a good practice to refresh tokens at regular intervals.