I am having difficulty getting Auth0 to return access tokens in JWT format. I need them in JWT format in order that I can verify them using a Java JWT library.
I am using Auth0 lock to login, and use /oauth/token to get the access token - I have tried setting the audience to our API identifier (in multiple places including the lock auth params, and the /oauth/token payload), without success - the access token is returned however not a JWT.
Alternatively, is there a Java library for validating "native" Auth0 access tokens?
var options = {
auth: {
redirectUrl: '<redirect_link>',
responseType: 'code',
params: {
audience: '<API_identifier>',
scope: 'openid offline_access'
}
},
allowedConnections: ['Username-Password-Authentication']
};
var lock = new Auth0Lock('<clientId>', '<auth0_Host>', options);
lock.show();
The returned code is used to POST to https://<host>/oauth/token with data:
client_id=<client_id>&redirect_uri=<redirect_url>&client_secret=<client_secret>&code=<returned_code>&grant_type=authorization_code&audience=<API_identifier>
Which is successful but the access token is not JWT, for example: "access_token":"sG99DAJI789SYgTj"
Using the scope openid returns an id_token in JWT format, but from reading the documentation this token should not be used for API authorisation.
It seems Auth0 is using OpenID connect, that is an extension of OAuth2. After a successful end-user authentication, the server returns an ID Token in JWT format and an access token
ID Token
The ID Token is a security token that contains Claims about the Authentication of an End-User by an Authorization Server when using a Client, and potentially other requested Claims. The ID Token is represented as a JSON Web Token (JWT) [JWT].
You can validate the ID Token at client side using any JWT library, but the validation rules for access tokens are different
3.2.2.9. Access Token Validation
To validate an Access Token issued from the Authorization Endpoint with an ID Token, the Client SHOULD do the following:
Hash the octets of the ASCII representation of the access_token with the hash algorithm specified in JWA for the alg Header Parameter of the ID Token's JOSE Header. For instance, if the alg is RS256, the hash algorithm used is SHA-256.
Take the left-most half of the hash and base64url encode it.
The value of at_hash in the ID Token MUST match the value produced in the previous step.
So, basically to validate it you need to compute the digest of the access_token using the hash algorithm of ID token, and check that it matches with the at_hash claim of ID Token
Related
I'm using centrifugo in conjunction with React + Laravel using the centrifugo/centrifugo docker image. It connects to centrifugo itself, but a problem appears, on the client side I use oauth2 bearer token instead of the usual jwt and pass it as described in the centrifugo documentation:
const centrifuge = new Centrifuge('ws://localhost:8001/connection/websocket', {
debug: true,
token: cookies.get(COOKIES.TOKEN) // here bearer oauth2 token
});
The connection itself takes place, but after the centrifuge it returns a disconnect with the signature that the token is incorrect:
{code: 3500, reason: 'invalid token'}
I have a question about how exactly to teach centrifuge to use bearer oauth2 token
I have:
An OpenID Connect identity / token server written in AspNet 6
A resource API that I want to protect with access tokens from the identity server, writen in Ruby / Rails
The issued tokens are assymetrically (public/private key) signed JWTs.
If I was writing the resource API in .Net, I would provide a URI for the token authority when setting up authentication, e.g.
app.UseJwtBearerAuthentication(new JwtBearerOptions() {
Authority = "https://uri.to.my.identity.server"
}
The JWT bearer authentication middleware would use this URI to find and retrieve the public key from the identity server, so that it can be used to validate token signatures.
I am looking for a similar approach when using the Ruby JWT gem (https://github.com/jwt/ruby-jwt)
The RSA example on that site just provides the public key explicitly, e.g.
rsa_private = OpenSSL::PKey::RSA.generate 2048
rsa_public = rsa_private.public_key
decoded_token = JWT.decode token, rsa_public, true, { algorithm: 'RS256' }
I could call the identity server discovery endpoint directly, but I was hoping there might be something part of the library (or another library) that would help with this.
I am trying to use an OAuth token to connect to Snowflake from Databricks.
I have configured using the official documentation (https://docs.snowflake.com/en/user-guide/oauth-azure.html#step-3-collect-azure-ad-information-for-snowflake).
When request the token I also retrieve what appears to be a valid token. The json in the format {'token_type': 'Bearer', 'expires_in': 3599, 'ext_expires_in': 3599, 'access_token': 'token here}'
However, when I try to use this token it comes as invalid - checking in Snowflake the result is the following:
Using https://jwt.ms/ to look at the claims in my token I find the following: aud, iss, iat, nbf, exp, aio, appid, appidacr, idp, oid, rh, roles, sub, tid, uti, ver.
Which claims are missing?
Most likely the issue issue is that the claim parameter set for OAuth integration object on Snowflake is not passing the right value. Review the following article which details the steps:
https://community.snowflake.com/s/article/Create-Security-Integration-User-To-Use-With-OAuth-Client-Token-With-Azure-AD
For my API testing, I have been getting the Authentication Token with the help of Postman. API uses OAuth2.0 for authentication.
While using Postman, I am entering the details like Token Name, Grant Type, Access Token Url, Client ID, Client Secret, Scope, Client Authentication. Once clicked on the Request Token, Bearer token is received and is updated in the Header of the request. Please refer the image attached.Getting OAuth2.0 bearer token with Postman
But now, I want to do it with Rest Assured using Java. Hence I want to know the code how do I get the Bearer token by using Rest Assured?
Assuming you are sending the client id secret and other details in the Query Parameters, for the GET and your response header access_token has the value you are looking.
public class Sample {
String oauth_token ;
#BeforeTest
public void sampletest() {
oauth_token = RestAssured.given().auth().basic("username", "password").
.queryParams("client_id", "client_id_value")
.queryParams("client_secret", "client_secret_value")
.queryParams("grant_type", "authorization_code")
.queryParams("redirect_uri", "https://someuritoredirect")
.queryParams("otherparams", "sampleparam")
.when().get("https://uri.to.get.hostname.com/oauth2/access_token")
.then()
.statusCode(200)
.extract().header("access_token");
}
}
I'm trying to implement a OAuth2 Authorization Server using DotNetOpenAuth. The client is JavaScript based thus incapable of holding any secrets. This is exactly the same problem like this question but with another framework.
The client requests (against the token endpoint) access_token and refresh_token with following parameters:
grant_type: password
username: foo
password: bar
This does work. Now I want use the refresh_token and make a request against the token endpoint with the following parameters:
grant_type: refresh_token
refresh_token: ABCDEF
This gives me the following response:
{"error":"invalid_client","error_description":"The client secret was incorrect."}
Which does make (at least some) sense because RFC6749 states that:
Because refresh tokens are typically long-lasting credentials used to
request additional access tokens, the refresh token is bound to the
client to which it was issued. If the client type is confidential or
the client was issued client credentials (or assigned other
authentication requirements), the client MUST authenticate with the
authorization server as described in Section 3.2.1.
If I change my request like so:
grant_type: refresh_token
refresh_token: ABCDEF
client_id: MYCLIENT
client_secret: CLIENT_SECRET
The problem is my client is not supposed to be confidential (because it is client side JavaScript after all).
This is how the client is defined:
New ClientDescription(ApiKey, New Uri(allowedCallback), ClientType.Public)
I searched through the DotNetOpenAuth source code and found no use of the ClientType. To me it looks like it is not used at all.
It is also not possible to the set an empty client secret, because the DotNetOpenAuth source code actively checkes against this (ClientAuthenticationModules.cs):
if (!string.IsNullOrEmpty(clientSecret)) {
if (client.IsValidClientSecret(clientSecret)) {
return ClientAuthenticationResult.ClientAuthenticated;
} else { // invalid client secret
return ClientAuthenticationResult.ClientAuthenticationRejected;
}
} else { // no client secret provided
return ClientAuthenticationResult.ClientIdNotAuthenticated;
}
If I take a look at MessageValidationBindingElement.cs:
if (authenticatedClientRequest != null) {
string clientIdentifier;
var result = this.clientAuthenticationModule.TryAuthenticateClient(this.AuthServerChannel.AuthorizationServer, authenticatedClientRequest, out clientIdentifier);
switch (result) {
case ClientAuthenticationResult.ClientAuthenticated:
break;
case ClientAuthenticationResult.NoAuthenticationRecognized:
case ClientAuthenticationResult.ClientIdNotAuthenticated:
// The only grant type that allows no client credentials is the resource owner credentials grant.
AuthServerUtilities.TokenEndpointVerify(resourceOwnerPasswordCarrier != null, accessTokenRequest, Protocol.AccessTokenRequestErrorCodes.InvalidClient, this.clientAuthenticationModule, AuthServerStrings.ClientSecretMismatch);
break;
default:
AuthServerUtilities.TokenEndpointVerify(false, accessTokenRequest, Protocol.AccessTokenRequestErrorCodes.InvalidClient, this.clientAuthenticationModule, AuthServerStrings.ClientSecretMismatch);
break;
}
Espacially the comment The only grant type that allows no client credentials is the resource owner credentials grant. makes me wonder. Does that mean that in my scenario the JS client should send username/password along? Nope this will raise the following exception:
AccessTokenResourceOwnerPasswordCredentialsRequest parameter 'grant_type' to have value 'password' but had 'refresh_token' instead.
Which is okay to me, because I don't want the client to keep the password.
So here my questions:
Did I unterstand something fundamentally wrong about the password-grant, refresh_token scheme?
As I see it in a JS client the client_id is public knowledge, so it does not serve any security purpose. Am I correct?
Does it makes sense to change DotNetOpenAuth to make use of the ClientType.Public?
Would it make any difference if I just use client_id and client_secret as not secret? E.g. just supply dummy values? What are the security implications?