If a user wants to remove him/herself from our service, we delete all of their data from our database, including Oauth tokens. The Oauth tokens we have are secure and persistent. As part of best practice we would like to totally invalidate the tokens as if they want to their Google accounts page and removed it there. Reading the Oauth documentation it was not clear to me if this is possible because all of the examples pertained to single-session or non-secure cases (and excuse my lack of "What did you try?"-ism but I'm trying to get a quick plan together on how to do this).
So
1) is this possible? Preferably on 1.0?
2) how to do this?
Yes, you can revoke tokens programmatically as if the user revoked access in their accounts settings page.
For AuthSub and OAuth 1.0, use the AuthSubRevoke token endpoint by making an OAuth-signed request to:
https://www.google.com/accounts/AuthSubRevokeToken
For OAuth 2.0, use the revocation endpoint like:
https://accounts.google.com/o/oauth2/revoke?token={refresh_token}
Related
I currently have a backend running on AWS Lambda and I'm using DynamoDB as a database. In Dynamo, there is a list of users and each user has specific permissions as to what routes they have access to through the API. There is no issue here.
I have not built the front end yet, but I will be logging in users using Google Auth, more specifically with the react-google-login component.
My question is: Once a user is logged in to the site, should I trust the JWT from Google (after verifying its legitimacy
here with the Google API) which returns the user information (Name, Email), lookup the user item inside of Dynamo to retrieve their permissions, and then serve their request?
This seems like the logical thing to do but I was looking for some confirmation. My one worry is that someone could use a supervisors name & email to authorize a request but if the lambda must accept a JWT created by Google as entry, I believe this problem is solved correct?
I have API Keys as well for every user for some external functionality, but I have that covered since it's just a Dynamo call away. My only concern is with the front end requests to Lambda since I do not want to roll my own auth/jwt.
Here is what I was envisioning.
Thank you!
Normally you should use access tokens for that purpose. The ID token should be meant only to authenticate the user, and the access token should be used to authorize access.
The best scenario would be to have a separate Authorization Server which could issue access tokens, and there are some open source solutions out there which you can use.
If you really don't want to setup your own AS then you could follow the scenario you outlined - the part with verifying JWT from Google and checking permissions in the DynamoDB is what the Authorization Server would normally do to issue an access token.
Just remember to thoroughly validate the incoming JWT - not only the signature with Google, but also check if that is a token created for your client / audience, etc. Otherwise someone could take a Google ID token JWT from their client and gain access to your API. This article lists best security practices when working with JWTs.
Also remember that ID tokens might have short expiration times and there are no means of automatically refreshing them (like you can do it with a refresh token in case of an access token), so you might end up having to reauthenticate quite often.
I want to use Oauth2 personally because I am trying to use the google APIs. I do not have intention of making an app for others. But the Credentials for Oauth2 require a authorized domain with certain pages already created.
So how can I use OAuth2 without the domains? Or is there another way to accept google apis without this process?
I looked into Oauth playground but the tokens get revoked within 24 hours. I need something where I do not constantly need to get new tokens or where I can automatically generate tokens.
I am working with Cloudfoundry UAA
I am not sure if it is possible in standard oauth2.
The situation is ->
User logs into the app
He receives an access_token and refresh_token
He can keep on acquiring new access_tokens which has original scopes
His access permission changes so new scopes are added for him
Now I need a new access token, without him to log in again.
Is it possible that I can use the same refresh_token and ask for access_token with modified scopes?
Thanks in advance!
In a word no. This would be a violation of the user's Trust.
And in case you have not heard, that is a bad thing.
There is an Internet Draft RFC OAuth 2.0 Incremental Authorization (put forth by Google)
There is some talk about it here.
I am creating an API for a mobile application using Rails 5. At the moment, I don't need three-legged authorization, as the API will only be consumed by our own mobile apps.
I'm thinking of choosing one of these two options:
Doorkeeper + Devise: I can implement OAuth 2.0 using Doorkeeper, but I will only be using the Password Credentials Grant, at least for now.
Rails' own ActionController::HttpAuthentication::Token module + Devise: This seems like the simpler way to go.
Honestly, I can't see the difference between the Token Access Authentication method and OAuth 2.0's Password Credentials Grant.
How would one choose one over the other? Is there any other option that needs to be considered?
If all you'll ever have is the "single purpose API" (only for mobile application), there is no big difference in terms of security.
But if you'd like to extend this API to be used by the external services, then, you'll be in a much better position with implemented OAuth 2.0 using Doorkeeper, because you can easily configure, for example, a Authorization Code Grant for them.
So, I'd say that "Doorkeeper + Devise" option is more future-proof, because it provides more options, while HTTP Token authentication is much simpler for implementation.
The two are conceptually different things:
"Token Access Authentication" specifies a protocol describing how a (possibly long-lived) token should be presented to the server securely. It says nothing about where the token came from or how it should be interpreted.
"Password Credentials Grant" is a part of the fully-fledged OAuth flow, describing the means of obtaining a (usually short-lived) token.
In a sense, you could use Password Credentials Grant to obtain a token using OAuth and then use this token in the Token authorization header to gain access.
The question then becomes - is it useful to do the extra roundtrip for exchanging the (permanent and secret) credentials for a (temporary) token, when we could instead use the (permanent and secret) token stored in the app to authorize immediately anyway.
As I see it, there are two potential benefits of using the full OAuth flow. Firstly, it lets you add other means of authorization for third parties naturally. Secondly, it lets you revoke the token at any moment and force a re-authorization using these other means (if you implement them, of course) without having to invent any wheels.
On the other hand, you can always add any additional "token generation" parts later, when they are needed. Thus, if your current plan is to hard-code credentials in code anyway, I'd suspect you are probably better off relying on Token authorization.
Not only is it one request shorter, it may also be slightly more secure than the Bearer authentication used in OAuth: if an attacker sniffs a Bearer token, they would (usually) get full token access to the server until its expiration. It is not the case with Token tokens (normally). Not that it all matters too much of course if the attacker could extract the shared secret from your app anyway.
As a security best practice, when an engineer/intern leaves the team, I want to reset the client secret of my Google API console project.
The project has OAuth2 access granted by a bunch of people, and I need to ensure that those (grants as well as refresh tokens) will not stop working. Unfortunately, I've not been able to find documentation that explicitly states this.
Yes. Client Secret reset will immediately (in Google OAuth 2.0, there may be a few minutes delay) invalidate any authorization "code" or refresh token issued to the client.
Client secret reset is a countermeasure against abuse of revealed client secrets for private clients. So it makes sense to require re-grant once the secret is reset.
I did not find any Google document states this explicitly either. But my practice proves that reset will impact users, also you can do a test on it.
And in our work, we programmers do not touch product's secret, we have test clients. Only a very few product ops guys can touch that. So I think you need to try your best to narrow down the visibility of the secret in your team. Rest is not a good way.