I am doing an app with a login/logout function and I will be storing the jwt issued by the server in the browser's local storage, for logging out I will destroy it so, if the same user wants to login again it will have to request for a new jwt. However, assuming that i will be using the same credential for the very same user, the same jwt token will be given based on its formula. So, is there a way to issue different jwt per login?
Related
I'm building a REST API and using AWS Cognito's user pools for authentication. I've got a "get_token" endpoint that returns the JWT access and refresh tokens to the user, which they use to authenticate access to the other REST endpoints provided by the API.
The access token has an expiration timeout. If the user of my API is an application program, what are the best practices for the application to handle when the access token expires? Does the application have to remember the username/password and re-authenticate to continue? Is using the refresh token to get a new access token and use that going forward the best approach?
Is there any documentation, suggestions anyone can point out that might help me out?
Cognito provides 3 types of tokens, id, access and refresh tokens when you login. The way this usually works is that you send either of the first two (depends on whether you want to be sending user payload information to your backend) to your backend via an Authorization header and verify the token there.
Your id and access tokens usually have a shorter expiration time compared to the refresh token. What you should do is, when the id (or access) token expire, you should use the refresh token to generate a new id (or access) token. When the refresh token expires that means that you can no longer generate new id/access tokens from it. In this case, the user (or app) must login again.
Im playing around and creating a custom access token system using JWT. I have already created a system for signing and validating JWT access tokens.
However, I find it hard to obtain information about what claims a refresh token should consist of.
Should i create refresh tokens identical to the access token - with a longer expiratiom time so that the same function that validates access tokens can be used to validate the refresh token?
A refresh token is typically an opaque value that is only used by clients to refresh access tokens. The flow works like this:
Web or mobile client implements OpenID Connect to authenticate users and get tokens - prompting the user to consent in some cases
An Authorization Server (AS) issues the tokens and stores details of this 'delegation' in a database - tokens are a pointer to this state
Client sends access tokens to APIs until a 401 expired response is received
Client then tries to refresh the access token by sending the refresh token to the Authorixation Server, which then looks up claim details from the stored state
I would make sure you get these responsibilities right - in particular avoid building your own AS and use a free one provided by experts, such as Curity Community Edition. Many security solutions will then be easier to develop.
I created a single page application (SPA), which relies on GitHub API v4.
The API requires an access token to access, so I created an input element to ask users to store their access token.
I want to persist the entered token so that users don't re-input the token after reloading or re-visiting the site, without building any backend server.
I tried few things to achieve my purpose:
save the token in localStorage
It is very easy, but there are security concerns to store secret information in the storage, so I rejected this approach.
use GitHub OAuth App to fetch tokens
It is not suitable because it requires to store client secret in my app. Since my app is SPA, the stored secret can be read by any user.
use Auth0 to bypass the authentification
At first, it seemed very easy to get GitHub access token, but it requires a backend proxy server to fetch the token as described here
Is it impossible to persist the token without any backend server?
If so, how to persist the token easily? For now, I came up with the below solutions:
use AWS Lambda to encrypt the token and save it into cookie
When users input the token, the app send the token to a Lambda function, which encrypt the token and response it into cookie. When users back to my app, the app send cookie to the Lambda function and decrypt the token and send it back to the app.
use AWS Lambda as a proxy to communicate with Auth0
As described here, Lambda functions can retrieve the GitHub access token via Auth0.
However, I don't want to do this because I don't want to use two external services just to persist the token.
I'm running a mock expressjs server in the back, and ember (ember-simple-auth) on the front with the ember-simple-auth-token addon. I'm using JWT tokens. I'm trying to decide whats the best way to send my user information. Usually when the user submits their credentials I create a new token, store a copy of it in the database (I'm using mongodb), send it to the frontend and then use the token to fetch information user information. I have a /auth/token (which authenticates and sends the token, makes a copy and stores it in the database) & /current_user route which gets called on the initial login, which uses the token and fetches the user info.
Is it better to simply send the user info in the initial payload of the token over having a separate route? Should I be storing a copy in the database in order to do a comparison and retrieve user information?
Also what are the advantages of a token refresh?
you are using Jwt-Auth for authentication.
-According to my knowledge after sending the user credentials u will respond with the token if credentials are correct otherwise send error.
-why are you saving the token in db ?.
you will send token to client (stateless). If client requests for data then we need to check for token. if it validates then return proper response otherwise return token error.
-why you need token refresh?
for security purpose. After response every time change the token.
TTL your token will be valid for some time (say 60 mins). after that it will be invalid.
This is how JWT works.
I am new to JWT(Json web token). I have a question in JWT about identifying user with token(already login one time) and with out token(first time login).
Is it like that if I pass only username and password at every time of login and server will create new JWT for me? If this is true than isn't it be vulnerable for user if some one get access to his/her username password and try to login with different PC or browser.(as JWT is always store on cookies or local storage)
Following your schema, if an attacker stoles user credentials (username/password), then, he could login in the system and get valid JWT tokens.
If the attacker stoles the JWT, also could login in the system before expiration time, and use the provided services (for example change password if it is available)
Then the security question is: protect the credentials and protect the token.
Mainly use HTTPS
Set expiration time short and rotate tokens
Use "secure" storage for tokens
Be aware that changing passwords or permissions could invalidate tokens before expiration time. Maybe you need a blacklist