I'm trying to set up a Vue3 SPA with a NestJS API in the back. I set up my Auth0 tenant and client to integrate with the SPA and plan to send the resulting JWTs to my API. In my SPA, I use the vue-auth0-plugin, which uses #auth0/auth0-spa-js under the hood.
I have successfully set up the Auth Code with PKCE flow, up to the point where I receive id, access and refresh tokens. However, something is wrong with the access token and I cannot understand why it is happening. The payload is invalid JSON and the token contains 2 consecutive .. When I paste the token into jwt.io, the header is decoded as follows:
{
"alg": "dir",
"enc": "A256GCM",
"iss": "https://xyz.auth0.com/"
}
I would be expecting:
{
"alg": "RS256",
"typ": "JWT",
"kid": "w1-e..."
}
I have not enabled JWT encryption as far as I know (I used the wizard to set up the SPA client), could anyone point out to me what I am missing? For the sake of completeness, this is the format of my auth request:
https://xyz.auth0.com/authorize
?client_id=REq...
&redirect_uri=http%3A%2F%2Flocalhost%3A1337
&scope=openid%20profile%20email
&response_type=code
&response_mode=query
&state=a2...
&nonce=bT...
&code_challenge=GjSw...
&code_challenge_method=S256
&auth0Client=eyJu...
Many thanks in advance.
As Gary said, the token is in JWE format. According to this Auth0 community post, the solution to the missing payload is to provide an audience parameter. You should be able to include that parameter in the query string to the /authorize endpoint.
I ended up finding this question and answer by testing the token at https://jwt.io/ which said the encoding was "A256GCM" and not "RS256" as expected.
The audience parameter fixed this, and should be passed as part of the authorizationParams object when creating the client when using "#auth0/auth0-spa-js": "^2.0.1"
auth0.createAuth0Client({
domain: "example.com",
clientId: "XXXXXXXXXX",
authorizationParams: {
redirect_uri: window.location.origin,
audience: "https://example.com/api/v1/"
}
}).then(async (auth0Client) => {
Related
My application is using OAuth to access the Youtube Data API. My OAuth callback is written in node and uses the OAuth2Client class from the "googleapis" npm package to exchange the authorization code for the access and refresh tokens.
Everything was working fine up to last week until suddenly I started getting the "invalid_grant" response during the authorization code exchange. I have tried everything to resolve this and am running out of ideas. My callback executes as a cloud function so I don't think that it would be out of sync with NTP.
My OAuth consent screen is in "Testing" mode and my email address is included in the test users. The odd thing is that even though the authorization code exchange fails, my Google account's "Third-party apps with account access" section lists my application as if the handshake succeeded.
Is there a limit to how many refresh tokens can be minted for my application? I am testing my implementation of incremental authorization so I have been going through the OAuth flow often.
Edit
I've included my code for generating the auth URL and exchanging the authorization code below. The invalid_grant occurs during the call to "oauth2.getToken"
async startFlow(scopes: string[], state: string): Promise<AuthFlow> {
const codes = await oauth2.generateCodeVerifierAsync();
const href = oauth2.generateAuthUrl({
scope: scopes,
state,
access_type: 'offline',
include_granted_scopes: true,
prompt: 'consent',
code_challenge_method: CodeChallengeMethod.S256,
code_challenge: codes.codeChallenge
});
return { href, code_verifier: codes.codeVerifier };
}
async finishFlow(code: string, verifier: string): Promise<Tokens> {
const tokens = await oauth2.getToken({ code, codeVerifier: verifier })
return {
refresh_token: tokens.tokens.refresh_token!,
access_token: tokens.tokens.access_token!,
expires_in: tokens.tokens.expiry_date!,
token_type: 'Bearer',
scopes: tokens.tokens.scope!.split(' ')
};
}
"oauth2" is an instance of OAuth2Client from "google-auth-library". I initialize it here:
export const oauth2 = new google.auth.OAuth2({
clientId: YT_CLIENT_ID,
clientSecret: YT_CLIENT_SECRET,
redirectUri: `${APP_URI}/oauth`
});
Looking at the logs, the only out of the ordinary thing I notice is that the application/x-www-form-urlencoded body looks slightly different than the example https://developers.google.com/identity/protocols/oauth2/web-server#exchange-authorization-code
The POST request to "https://oauth2.googleapis.com/token" ends up looking like this:
code=4%2F0AX4XfWiKHVnsavUH7en0TywjPJVRyJ9aGN-JR8CAAcAG7dT-THxyWQNcxd769nzaHLUb8Q&client_id=XXXXXXXXXX-XXXXXXXXXXXXXXX.apps.googleusercontent.com&client_secret=XXXXXX-XXXXXXXXXXXXXXX-XX_XXX&redirect_uri=https%3A%2F%2Fapp.example.com%2Foauth&grant_type=authorization_code&code_verifier=KjOBmr4D9ISLPSE4claEBWr3UN-bKdPHZa8BBcQvcmajfr9RhWrgt7G429PLEpsP7oGzFGnBICu3HgWaHPsLhMkGBuQ2GmHHiB4OpY2F0rJ06wkpCjV2cCTDdpfRY~Ej
Notice that the "/" characters are not percent-encoded in the official example, but they are in my requests. Could this actually be the issue? I don't see how the official google auth library would have an issue this large.
The most common cause for the invalid_grant error is your refresh token expiring.
If you check oauth2#expiration you will see the following
A Google Cloud Platform project with an OAuth consent screen configured for an external user type and a publishing status of "Testing" is issued a refresh token expiring in 7 days.
Once you set your project to production your refresh tokens will stop expiring.
Is there a limit to how many refresh tokens can be minted for my application?
No but you have a limit of 100 test users.
I have a react native app authenticated with Auth0.
I have an API that uses react native.
When a user signs in, i take the accessToken that is given for that user, and I make request to the API with the accessToken set as the authorization header.
I do so like this:
const requestHeader = {
headers: {
Authorization: `Bearer ${accessToken}`,
}
}
axios.post(API_BASE + '/api/example/', requestHeader)
The accessToken is something short like this: aBQdd0kOvb1pNj-9XDj_C6bKWkMg9D_q
When I try to validate the request with the API, I get this error:
UnauthorizedError: jwt malformed
I know i'm getting this error because the access token isn't a JWT.
I'm validating in the API like this:
exports.checkJwt = jwt({
secret: jwksRsa.expressJwtSecret({
cache: true,
rateLimit: true,
jwksRequestsPerMinute: 5,
jwksUri: 'https://dev-0p1doq9r.auth0.com/.well-known/jwks.json'
}),
audience: 'ddasdsfasdfasd',
issuer: 'safsdfasdfasdfafsdf',
algorithms: ['RS256']
});
I know that accessToken needs to be transformed into a JWT on the client, BUT HOW? I have not found any documentation for this; I have also not found what other properties need to be included in the JWT for validation.
I have read many articles in stackoverflow and have seen lots of youtube videos, but failed to find the example code which is demonstrating about the flow of saving jwt to localstorage - send back to server with authorization header for verifying.
Here is what I want to do.
When the client logs in to the server, server gives token and saves it to the client localStorage (or sessionStorage).
Whenever the client calls an api which can be accessed only with the token,
client retrieves the token back from the localStorage, and send that token with the authorization header (req.headers.[x-access-token] or req.headers.[authorization]) to the server.
But all of the articles I've been read is explaining this issue with the Postman which does not show how to store it to the localStorage and put it in the authorization header.
Do I have to use localStorage.setItem when the server gives the token to the client, and use and localStorage.getItem and new Headers() with append() or axios before sending that token back to the server?
Examples don't have to be for the express user, but I'd like to get the glimpse of ideas.
You can store your jwt token in localstorage and when ever you make a API call you can add the token to headers as token. if you are using axios you can attach you token to headers like this. Here the token is stored in localstorage with the key 'jwtToken'
axios.post('http://yourendpoint',data,{ headers: { Authorization:localStorage.getItem('jwtToken') } })
.then(response=> console.log(response))
.catch(error => console.log(error));
};
it's easy just Follow me
First of all you have to save the Token(or access token) to the local storage,
in the login component when you are sending request for login do the below:
signin:function() {
axios.post('http://Somthing/log-in/',{
username: this.username,
password: this.password,
})
.then( (response) => {
let token = response.data.access;
localStorage.setItem("SavedToken", 'Bearer ' + token);
axios.defaults.headers.common['Authorization'] = 'Bearer ' + token;
(this.$router.push({name:'HomePage'}));
})
So now the problem is whenever you refresh the Homepage you got 401 error and the solution is : just add this :
{ headers: { Authorization:localStorage.getItem('SavedToken') }}
to the end of each request that need the Token in its header, like below:
axios.get('http://Something/', { headers: { Authorization:localStorage.getItem('SavedToken') }})
.then(response =>{
//something
})
Notice that the token that i used in this explanation was SIMPLEJWT , if you are using somthing else maybe you have to change 'Bearer' to somthing else.
First you have to create or Generate Token through Jwt (jsonWebTokens) then either store it in local Storage or through Cookie or through Session. I generally prefer local storage because it is easier to store token in local storage through SET and retrieve it using GET method. and after retrieving it through get you can verify it through jwt and also authenticate it with bearer authentication..
And for headers add Authorization
fetch("/users", {
method: "Get",
headers: {
"content-type": "application/json",
Authorization: "Bearer" + localStorage.getItem("token")
}
JWTs should never be stored in your localStorage
In fact, they shouldn't even be stored in your cookies, unless you are able to implement very strict CSRF protection
Checkout this for motivation
JWT as an id_token is like your user credentials
JWT as an access_token is like your session token
One option is in-memory. Checkout this for a deep dive
When I am trying to login with username and password to get token_id and access_token using postman with auth0 by installed using Postman Collection in Postman
I get an error in login method of database:
You are correct that the /oauth/ro endpoint is being deprecated. You should be making a call to /oauth/token instead.
Your question is unclear.
Try to send the first request with login/password by standard authentication (Authorization tab > Type > Basic Auth).
As the following steps I recommend to check the relevant Postman manual: Using the Auth0 API with our Postman Collections and use the predefined collections from Auth0 API Documentation (press on "Run in Postman" button).
In addition, it's strongly recommended to use the Native Postman app, but not its deprecated Chrome extension.
I was able to get the id_token by using the /oauth/token endpoint, and passing scope=offline_access. Here is an example of my POST payload (Python code):
{
"grant_type": "http://auth0.com/oauth/grant-type/password-realm",
"scope": "offline_access",
"client_id": client_id,
"client_secret": client_secret,
"username": username,
"password": password,
"realm": database_connection,
}
Response:
{
access_token: "lK...",
expires_in: 1000,
id_token: "eyJ...",
refresh_token: "ym...",
}
I am working on a Web API where I implemented JWT based authentication. I am not using neither PasswordJS middlware nor Oauth protocol. Its basically JWT npm which I use to sign and verify tokens.
The whole concept of token are pretty clear, but I very much confused with the term 'token scheme' and cannot understand what it is used for.
What I would like to understand is: do I need to use some sort or custom 'JWT' scheme and validate it when token is send back to server for further requests, or this concept is used only by Oauth, and what I need is only send the plain token?
var accessToken = jwt.sign({
userID: user.id,
isAdmin: user.isAdmin
}, config.userSecret, {
expiresIn: 600
});
res.json({
success: true,
user: {
id: user._id,
name: user.name,
username: user.username,
accessToken: 'JWT ' + accessToken,
}
});
jwt.verify(accessToken, secret, function(err, token){...}); //throws error when token is passed with the custom scheme
Exactly what scheme you are using isn't that important in this case, because you are parsing the content of the Authorization header manually anyway.
Basically, the token is sent from the client to the server on an HTTP header called Authorization. In front of the token you put the name of the scheme. So the Authorization header might look something like this:
Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9.TJVA95OrM7E2cBab30RMHrHDcEfxjoYZgeFONFh7HgQ
(The list of allowed names is here. For JWT it's usually Bearer. You are technically not following the OAuth 2.0 bearer scheme according to RFC6749, but it's usually called Bearer anyway.)
You have to manually take the token (ey...) and verify it with jwt.verify() to get its payload.
const headerExists = req.headers.authorization
if (headerExists) {
let token = req.headers.authorization.split(' ')[1];
jwt.verify(token, auth.secretjwtkey, function (err, decoded) {
if (err) {
res.status(HttpStatus.UNAUTHORIZED).json('Unauthorized');
} else if (decoded.role === 'admin') {
next();
} else {
res.status(HttpStatus.UNAUTHORIZED).json('Unauthorized');
}
})
} else {
res.status(HttpStatus.FORBIDDEN).json('No token');
}
You can see from the example middleware above that I don't care about the Bearer string on the Authorization header, only the token itself. You could, of course, check that it actually was Bearer and not something else though.
So the moral of the story is that:
You send the token from client to the server on the Authorization header. You have to set up the front-end so that happens.
You prepend Bearer in front of the token (or one of the other in the allowed list, but bearer is recommended).
You decode the token by reading the second part of the string that is on the Authorization header and then feed it to jwt.verify().
See here for more details.