The OAuth2 specification for Client Credentials (https://www.rfc-editor.org/rfc/rfc6749#section-4.4) says that "The authorization server MUST support the HTTP Basic authentication scheme for authenticating clients that were issued a client password" but MAY support including the client credentials in the body of the message.
I can see from the Microsoft Graph API documentation that they describe using this latter method.
However, does this mean that the Basic Authentication approach is NOT supported or just that the alternative approach is preferred?
Thanks.
Please see token_type in the response.
token_type Indicates the token type value. The only type that
Microsoft identity platform supports is bearer.
For your question in the comment, if the access token has expired, it will show an 401 error.
Related
I'm learning about the OAuth /introspect endpoint as a means to validate an Access Token. I'm using Okta, which I think is relevant to the question.
I've read online that the /introspect endpoint is intended to be called by an OAuth Resource Server (for example, an OAuth Client would call a Resource Server, providing an Access Token, and the Resource Server would call the /introspect endpoint to make sure the token is valid).
However, the /introspect endpoint (at least with Okta) requires you to provide the OAuth Client credentials (either as a basic auth header, or in the case where there is no client secret, just a client_id request param).
So, how can the Resource Server call the /introspect endpoint when it doesn't have the OAuth Client ID and/or secret? This is making me wonder if the /introspect endpoint is meant to be called by the OAuth Client instead, which to me, doesn't seem as useful.
Please refer to this article. Resource server needs to be a registered client application at Okta and client credentials in /introspect refer to this client's.
Based on my understanding the introspection endpoint is meant to be called by an API resource.
This endpoint is used by the API resource in order to validate the bearer token provided with an incoming HTTP request issued by a client application.
Most of the times this happens when the provided bearer token is a reference token, so the API resource server needs to known whether the provided reference token is associated with a valid access token. This information must be asked to the secure token server via a call to the introspection endpoint.
You can find more information here in the identity server docs. Identity server is a .NET implementation of the openid connect protocol, which is based itsel on oauth2.
This is a documentation that shows you how to call the introspection endpoint programmatically. This documentation is specific for a .NET library called identity model, but this is not relavant for your question, because the library simply implements the protocol.
As you can see in the example of the linked documentation, the client id that you need to specify when you call the introspection endpoint is simply the name of the API resource. The client secret is the API resource secret that you have defined for your API resource.
So, the source of your confusion is simply a terminology overload. In the context of the call to the introspection endpoint both of the following equations hold true:
client id == API resource name
client secret == API resource secret
This docs confirm both of my assumptions.
If it helps here are a few resources of mine, to add to Enrico's answer:
API Setup - see step 6 - you have to register an OAuth Client for the API
API OAuth Messages - see steps 16, 17 and 19 for the three types of response your API needs to deal with
API Code - for an example implementation in NodeJS
I create a clientid, and clientcredentials in google console. when I request the token with grant_type=client_credentials. I got 401 unauthrorized.
{
"error": "invalid_client",
"error_description": "Unauthorized",
"error_uri": ""
}
The error means that you are not authenticated. Also client_credentials is not a valid value for grant_type that I am aware of.
The only ones I know of are
authorization_code
refresh_token
It looks like grant_type=client_credentials is part of the RFC for Oauth2 but its not something I have seen implemented in Googles Authentication servers.
Anwser: No to my knowledge you cant use grant_type=client_credentials with Google APis.
update: just got word back from Google. I was correct they do not support this grant_type.
The Grant Type: Client Credentials (client_credentials) is not supported by Google OAuth 2.0. Google only supports two types of OAuth grants:
authorization_code
refresh_token
The Grant Type Client Credentials is used for obtaining an Access Token for the account specified by Client ID and is not used for User Authentication. This type of access is not supported by Google.
The OP was also using Basic Authorization: base64(Client_ID:Client_Secret) and this form is not supported by Google.
There are a few OAuth servers that support these additional forms such as IBM's App ID. Google OAuth 2.0 is not one of them.
I've been trying to learn some server side frameworks these days. I am not an expert of oauth2, but I had use an api with a team. They gave me an access using Resource owner credentials grant, with a grant_type as password, client_id and client_secret. I can log in on multiple browsers at the same time. As I have tried sails js oauth 2 and laravel passport oauth2. I got confused. Both of them using grant_type password revoke my old access_token. Using laravel passport and sails js oauth2 with grant_type password. I can log in only on one device or browser at a time. I'm confused which one is the right thing to do.
Is this how oauth2 really works? you can only log in and use one access token?
If this is the standard way, revoking the old access token. What type of grant type should I use. so my multiple devices can log in at the same time?
The behavior --- whether issuing a new access token invalidates existing access tokens or not --- depends on OAuth 2.0 server implementations. The OAuth 2.0 specification (RFC 6749) does not impose any restrictions on the behavior.
In fact, a certain OAuth 2.0 server implementation provides a feature to enable server administrators to configure the behavior. The following is a screenshot of the description about the configuration item ("Single Access Token Per Subject").
So, what matters is not grant_type but the implementation policy of the OAuth 2.0 server you are using.
I am looking for concrete information regarding the state of RFC7636 (proof key for OAuth token exchanges) in Google's OAuth2 APIs.
Google exposes an OAuth 2.0 and OIDC provider API where access tokens can be obtained. There is a proposed standard described in RFC7636 for using proof keys in token exchanges which we have started using in our integrations with major identity providers. Some accept the proof key, others ignore it; Google seems to be aware of it but fails to validate the proof key. I have not been able to find any mention of this wrt Google.
In concrete terms, when following the authorization code flow of OAuth 2.0 with Google as the provider we generate a random number, hash it using SHA256, base64 URL encode it, and then pass it to https://accounts.google.com/o/oauth2/v2/auth as parameter "code_challenge" and "code_challenge_method" as per the spec.
The endpoint accepts the parameters and issues an authorization token as usual. When obtaining the access token we call https://www.googleapis.com/oauth2/v4/token with the code_verifier; the endpoint returns the following HTTP 400 error which suggests that there is some awareness of code verifiers:
{
"error": "invalid_grant",
"error_description": "Missing code verifier."
}
Google's OAuth documentation at developers.google.com/identity/protocols/OAuth2 does not mention any of these parameters; the API playground does not extend to playing with the OAuth2 auth and token endpoints. Any insight would be greatly appreciated.
I was having this same problem using AppAuth and an Android clientId. In order to fix it I had to set a matching 'code_verifier' field on both the authorization and token requests. You can find a more in depth description in this post: invalid_grant trying to get oAuth token from google
The OpenID Connect Spec OAuth 2.0 Multiple Response Type Encoding Practices states that multiple response_type can be combined, e.g. response_type="code token". Now I'm wondering what it's good for to request an authorization code and the token. Isn't the auth code superfluous if you have the token already?
OAuth 2.0 is a protocol framework on top of which other protocols can be built and OpenID Connect is an example of such a protocol.
Especially for OpenID Connect it makes sense to use combined response types because there are 2 tokens in play: the access_token and the id_token. Using "response_type" the client can request how each of the tokens should be delivered.
In the example that that you give, the access_token will be delivered through the front channel as part of the authentication response but the id_token will be delivered when exchanging the "code" for an id_token at the token endpoint in a backchannel call.
A reason for doing this may be that the id_token, which is a signed JWT, does not have to be verified locally when obtained from a proper TLS protected token endpoint, so the client code can be simple. The access_token is opaque to the client anyhow and does not benefit from that.
I've never seen this used in practice. Yes, having the token already kind of diminishes the value of using the code flow.