Question: What is the difference between the following OAuth 2.0 authorization URLs:
In various documents example I see reference to this authorization URL:
https://accounts.google.com/o/oauth2/auth
In other documents example I see reference to this authorization URL:
https://accounts.google.com/o/oauth2/v2/auth
These URLs are used for code like this (Python):
authorization_base_url is one of the above URLs.
authorization_url, state = gcp.authorization_url(
authorization_base_url,
access_type="offline",
prompt="select_account",
include_granted_scopes='true')
I am in the process of debugging another Google OAuth 2.0 Refresh Token problem and I am trying to clarify the exact solution link. I am seeing behaviour that does not match documentation.
There's no documentation of the differences but in general they are different versions of the same endpoint.
A newer version may introduce improved or changed behavior though protocol-wise and interoperability-wise there should be no difference to the consumer. They're all OAuth 2.0/OIDC compliant but within the spec there are different optional behaviours that may be implemented.
As an example of that: when an error occurs on the Google side, Google may decide to stop the flow and show this error to the user, or alternatively return an error to the Client as OAuth 2.0 allows you to do. Both are valid behaviors and different versions of the Authorization endpoint may implement a different flavor.
Related
Relevant stackoverflow ticket: signin for server-side apps and plus deprecation
As mentioned in above stackoverflow question by David, We also have already implemented google sign in with OAuth 2.0 based flow, we are not passing any scope details & after google authentication
when return back to our site it seems adding additional scope of https://www.googleapis.com/auth/plus.me and might be due to this we also get this deprecation notification.
sample scope return from google after OAuth 2.0 authentication:
scope=openid email https://www.googleapis.com/auth/userinfo.email https://www.googleapis.com/auth/plus.me
So our question is:
Q1: Does OAuth 2.0 flow work fine after this google plus deprecation?
Q2: Do we required to change scope instead of https://www.googleapis.com/auth/plus.me need to use anything else to make it working as it is after plush deprecation with same code and flow with OAuth 2.0, if so any suggestion how we can override scope in OAuth 2.0 to not forcefully apply https://www.googleapis.com/auth/plus.me might be from google.
Q3: Including the plus.me which is we guess what I'm concerned about. How do we control or stop this? Or maybe We don't need to do anything and Google will take care of it themselves before they shutdown the plus.me scope? [As mentioned David in above relevant question]
There has been some confusion, but to try and answer your questions
Does OAuth 2.0 work after Google+ Shutdown
Yes.
Google's OAuth shouldn't be dependent on Google+ at all, although some assumptions do make it look that way.
If you're using OAuth 2.0 with non-plus scopes and non-plus methods, you're fine.
Do we need to change the plus.me scope?
Yes. If you are explicitly requesting the scope https://www.googleapis.com/auth/plus.me, then you will need to remove this scope from your requests.
If you, and your libraries, are not explicitly asking for this scope - then you're good.
What about Google including the plus.me scope?
You don't need to worry about this. As they said in their corrected email
The email listed that one or more of your projects are requesting the
“plus.me” scope, and would thus be affected. We would like to clarify
that only projects directly requesting the “plus.me” scope are
affected. This scope may have been listed in some emails, even if not
directly requested by your project. We apologize for any confusion
caused.
So you just need to make sure that you aren't explicitly requesting the scope.
I'm writing my own codes for the OpenID Connect protocol. Basically, I intend to write my own provider and related stuff on Google App Engine's platform using Jersey and Google's datastore via Objectify library.
I'm in the middle of implementing the (access/refresh) token endpoint and there's this client authentication that I need to take care of. I'm just wondering if there are preset authentication schemes' keywords that I could send if in case the client did not have client_secret_basic set during the registration process (or whatever's set in the datastore entry.)
For a failed client authentication with the following methods, the scheme is used as response in the WWW-Authenticate header (401):
client_secret_basic: Basic,
client_secret_post: ???,
client_secret_jwt: ???,
private_key_jwt: ???,
none: obviously none.
I've looked at some open source implementations, nimbus' and OAuth-Apis', but they don't seem to handle this minor issue (they only respond with the generic error response defined in OAuth2 rfc6749#section-5.2.)
If there are no predefined keywords, then I suppose I'll have to make up my own. But it would be great if they exist.
The authoritative list for these is at IANA. There, you can find these handfuls:
Basic
Bearer
Digest
HOBA
Mutual
Negotiate
OAuth
SCRAM-SHA1
SCRAM-SHA-256
vapid
Which of these is client_secret_post, client_secret_jwt and private_key_jwt? None. You'll need to map those to one from the registered list above or return your own values. Better yet, you can submit a draft to the OAuth working group or the OpenID Foundation to get the above IANA registry updated with something that makes sense for these missing cases. Then, we can all interop :-)
I'm trying to authorize my standalone application. But after I click "Allow" it always redirects to http://oauth.vk.com/error?err=2 and gives this as response body:
{"error":"invalid_request", "error_description":"Security Error"}
Here's the request URL (I do have correct client_id):
https://oauth.vk.com/authorize?client_id=...&scope=messages,offline&redirect_uri=https://oauth.vk.com/blank.html&display=page&v=5.37&response_type=token
It seems that I've tried everything:
Turning application on and off
Passing scope as bit mask
URI encoding some parameters to have correct URL
and so on
After hour of searches I've found this.
So, it means that user has an old session and must re-login in browser.
Space in state parameter causes this.
OAuth 2 RFC, sections 4.1.1 on authorization request and 4.1.2 on authorization response, recommends using state parameter to maintain state in authorization code flow, particularly to prevent CSRF.
When I set this field to CSRFTOKEN123 http://my.site/next/url, I got this error. Replacing (space) with : to get CSRFTOKEN123:http://my.site/next/url helps.
By the way, I couldn't find any mention of state parameter on VK documentation website but VK OAuth 2 authorization system actually supports it. It couldn't be called OAuth 2 otherwise. So I find it legit to use state parameter.
The topic https://vk.com/topic-17680044_30635058 mentioned by author is closed now, current discussion is https://vk.com/topic-1_24428376. There are number of questions on this. All in Russian.
I feel silly even asking this question, but am at the limits of my understanding, and am hoping someone can provide some context.
I'm looking at the following (https://stormpath.com/blog/token-auth-for-java/) which states:
The access_token is what will be used by the browser in subsequent requests... The Authorization header is a standard header. No custom headers are required to use OAuth2. Rather than the type being Basic, in this case the type is Bearer. The access token is included directly after the Bearer keyword.
I'm in the process of building a website, for which I'll be coding both the back-end REST service, as well as the front-end browser client. Given this context, why do I need to follow any of the guidelines given above? Instead of using the access_token, Authorization and Bearer keywords, what's stopping me from using any keywords I like, or skipping the Bearer keyword entirely in the header? After all, as long as the front-end and back-end services both read/write the data in a consistent manner, shouldn't everything work fine?
Are the keywords and guidelines given above merely best-practice suggestions, to help others better understand your code/service? Are they analogous to coding-styles? Or is there any functional impact in not following the above guidelines?
Given this context, why do I need to follow any of the guidelines given above?
Because they are standardized specifications that everyone is meant to conform to if they want to interact with each other.
Instead of using the access_token, Authorization and Bearer keywords, what's stopping me from using any keywords I like, or skipping the Bearer keyword entirely in the header?
Nothing, except that it won't be OAuth anymore. It will be something custom that you created for yourself that noone else will understand how to use, unless you publish your own spec for it.
After all, as long as the front-end and back-end services both read/write the data in a consistent manner, shouldn't everything work fine?
Who is to say that you alone will ever write the only front-end? Or that the back-end will never move to another platform? Don't limit yourself to making something custom when there are open standards for this kind of stuff.
Are the keywords and guidelines given above merely best-practice suggestions, to help others better understand your code/service?
No. They are required protocol elements that help the client and server talk to each other in a standardized manner.
Authorization is a standard HTTP header used for authentication. It has a type so the client can specify what kind of authentication scheme it is using (Basic vs NTLM vs Bearer, etc). It is important for the client to specify the correct scheme being used, and for the server to handle only the schemes it recognizes.
Bearer is the type of authentication that OAuth uses in the Authorization header. access_token is a parameter of OAuth's Bearer authentication.
If you use the Authorization header (which you should), you must specify a type, as required by RFCs 2616 and 2617:
Authorization = "Authorization" ":" credentials
credentials = auth-scheme #auth-param
auth-scheme = token
auth-param = token "=" ( token | quoted-string )
So, in this case, Bearer is the auth-scheme and access_token is an auth-param.
Are they analogous to coding-styles?
No.
Or is there any functional impact in not following the above guidelines?
Yes. A client using your custom authentication system will not be able to authenticate on any server that follows the established specifications. Your server will not be able to authenticate any client that does not use your custom authentication system.
I have two questions about Box's Oauth2 API in a testing environment.
Is it possible to have multiple redirect_URI addresses? I'd like to use one address for production (e.g., https://my_site.com/box_redirects_here), one for ongoing development (http://localhost:8000/box_redirects_here) and one for automatic UI tests (http://localhost:8001/box_redirects_here). As far as I could see, the only way to do that would be to create three different Box applications - is there an easier way? BTW, both Dropbox and Google Drive do support multiple redirect URIs.
I have a set of automatic tests that I'd like to run a few times a day. The challenge I'm facing is that every time I run these tests, my refresh_token is invalidated, and I can't use it again - which means I can't run the same set of tests a few hours later without manually getting a new token. One solution would be to save the refresh token, for example in a file, so I could reuse it across testing sessions. But:
It's really cumbersome.
if different developers are running these tests from different machines with no common file system that doesn't really work.
Again, for whatever reason this doesn't seem to be an issue with Google Drive or with Dropbox.
This is not currently possible, and I agree that would be nice.
Your best option is to save the access/refresh token pair to a file or a database (in the event that there's no common filesystem.) The OAuth2 spec grants implementers wide latitude on how they issue refresh tokens, if they issue them at all (I don't think Dropbox does.) While Box's implementation makes integration testing a bit challenging, I think that it ultimately hews most closely to the spec's recommendations.
For your first question, you might be able to get close to what you want by using the redirect_uri query parameter. Although you won't be able to supply an arbitrary redirect URI, you can give one that has the same base URL as the redirect URI in your app console.
From the OAuth tutorial:
Wildcard redirect_uri values are also accepted in the request as long as the base url matches the URI registered in the application console. A registered redirect_uri of https://www.myboxapp.com can be dynamically redirected to https://www.myboxapp.com/user1234 if passed into the request redirect_uri parameter.
For your second question, John is right - Box invalidates a refresh token after it has been used. Although this can be annoying, it's also more secure.