Can someone tell me how to send jwt authentication token for every rest request send from asp.net core to the web APi,
Does there is need to create a secret key to sign the token signature?
Can we just send the token without signing the token.
This is very broad question.
Short answers:
Tokens are usually sent in cookies. Certain solutions also store tokens in browser localstorage or sessionstorage and then add the token in every request header
Yes, signing the token is mandatory. Otherwise, the server won't have a way to determine if the token has been tampered by an attacker or client. Signing is required for security
But there are much more to it. Refer to the following for details:
https://stackoverflow.com/a/54258744/1235935
https://stackoverflow.com/a/54011649/1235935
https://www.rfc-editor.org/rfc/rfc7519
https://www.rfc-editor.org/rfc/rfc6749
Related
I'm using .NET 6 with HttpOnly cookie-based JWT authentication in my WebAPI, and I'm now implementing token refresh.
I store the JWT and a Refresh Token in cookies, e.g.:
X-Access-Token: eyJhbGciO...
X-Refresh-Token: d8085ec8-d0bc-4e5c-b6b6-cd76146c419f
Most flows I've found for token refresh look like this, with the client calling the /refresh endpoint to get a new JWT:
client sends request to server
server rejects request with a 401 Unauthorized
client requests new JWT (expired JWT and Refresh Token automatically sent to server in cookie)
server validates cookie Refresh Token, generates new JWT and Refresh Token, assigns to cookies
client sends original request to server, with the new JWT and Refresh Token in the cookie
My question is:
When the initial request with the expired JWT is received by the server, since the server already has the refresh token (sent in the X-Refresh-Token cookie), can't the server issue a new JWT and Refresh Token at that time and successfully complete the request? This completely eliminates the need for a separate request and response to refresh the tokens. This is the flow:
client sends request to server
JWT is expired, but Refresh Token is valid
server creates new JWT and Refresh Token, assigns to cookies
server successfully completes the request
Is there a vulnerability or security risk implementing the refresh this way? I cannot think of one, but I could not find any examples with this flow.
Thanks!
Why are you using JWT access tokens? If the server could respond with an updated access token by looking at the refresh token, then why wouldn't the server just look at refresh tokens every time, and then the JWT access tokens aren't needed?
The point of using JWTs, and access tokens in general, is that it allows stateless authentication with services that have no access to the refresh token store. Usually, you will have an authentication service, it stores the refresh tokens, and calls to /refresh get routed to it, and it will validate the refresh token, and issue the access token. Then, calls to other services are able to validate the access token, without needing to make any calls on the authentication service. So, the reason why they don't just reply with a new access token when authentication fails is because those services are incapable of checking the refresh token, they don't have access to the refresh token store, only the authentication service does.
If however your application is one big monolith, where every endpoint is hosted by the same server and therefore is capable of checking refresh tokens and issuing access tokens, then there is absolutely no reason for you to be using access tokens or JWTs in general. You should just use refresh tokens, which, in this case, would be better called a session token.
I read a few articles, but still not able to derive a good enough understanding. So far, I understand that:
After successful authentication, server sends back an access token (ex. jwt) that a client uses to make authorized subsequent requests.
But this access token can get stolen from the client. So we'd make it short-lived. And, we use refresh token to renew the access token without having the user to follow authentication process again.
Questions:
Where do we keep the refresh token? Do we send it back to the client on initial successful authentication? Or do we store it on the server somewhere (DB)?
If we're sending it back to client and the client is using the refresh token to generate more short-lived access token, than that refresh token can also be stolen. How does it make the process secure? Wouldn't keeping a long-lived access token safe suffice?
Thank you.
To answer your first question, Ideally refresh token should be returned to the client along with the access token.
In order to make your access token/refresh token more secure you could add in some browser specific metadata into the JWT that you generate and verify on the server side to avoid token side jacking.
To learn more on some good REST security practices you can refer to this link
https://github.com/OWASP/CheatSheetSeries/tree/master/cheatsheets
we plan to introduce an API management solution and we're currently setting up a proof of concept with WSO2 AM. We want to use the WSO2 API gateway to check whether a certain consumer application is allowed to use an API and to throttle the request rate.
I work on the identity workflow and I wonder how a consuming application can pass a JWT token to the backend service with WSO2-AM in between.
First, this is our current scenario:
Without API gateway
The consuming application gets a JWT token for its carbon user from an identity provider. The JWT contains some claims about the user, e.g. the roles he/she belongs to.
The app calls the service an passes the JWT token in the Authorization HTTP header like: Authorization: Bearer
The service validates the issuer and signature of the JWT and retrieves the claims from it.
So, this is pretty straight forward. Now we put an API gateway in between the application and the service:
With API gateway
The consuming application gets a JWT token for its carbon user from an identity provider.
The consuming application uses OAuth2 to get an access token for the following API calls. We can use the client_credentials grant type and simply pass the the client id and client secret. I haven't yet tried it, but we could possibly use the JWT grant type (see https://docs.wso2.com/display/ISCONNECTORS/Configuring+JWT+Grant+Type) and use the JWT for passing user information to the API gateway.
The API gateway validates the JWT against the public key of the identity provider when using the JWT grant type.
An access token is returned to the app.
The app sends an API request to the gateway and passes the access token in the Authorization HTTP header.
The gateway validates the access token.
The gateway forwards the API request to the service.
And there is my problem: How can the JWT from 1/2. be passed to the service?
There is a documentation for "Passing Enduser Attributes to the Backend Using JWT" (see https://docs.wso2.com/display/AM210/Passing+Enduser+Attributes+to+the+Backend+Using+JWT), but this would introduce a new JWT, issued and signed by WSO2-AM, and I'm not sure, whether this JWT contains all information from the JWT used to create the access token (or even the original JWT).
Another way I could think of is using a custom HTTP header for passing the JWT through the gateway to the service. I cannot use the Authorization header (as we do without the API gateway), because WSO2-AM expects the access token in that header.
Since I'm not happy with either solutions, I want to ask the experts: How would you solve this?
Thanks,
Torsten
The only possibility I can think of is to send the JWT token in a custom Header for the backend service.
Trying to implement a secure authentication method with JWT for an API which will be consumed for many clients including web (Single Page App), desktop, mobile I've came up with this system:
Client calls /auth/login with username and password set
After verifying server returns two tokens an auth_token and a refresh_token
Auth token is short lived 15 minutes and is used on every following API call
Refresh token is long lived maybe a 12 hrs to a week BUT is signed with a secret key in the format user_pass + long_string
After the token expires a called to /auth/renew is called
The auth token is sent to check how long it's expired (no longer than an hour)
The refresh token is sent as well and is validated using the user's password
If refresh token isn't expired and the auth token isn't expired for a long time, a new auth token is sent back
If the user's password has changed, the refresh token is invalid and the user is required to re-authenticate after their existing short lived auth token has expired
While there is a small window for the auth token to be expired and still be valid, and there is calls to the database made; is this an overall secure way to authenticate using JWT and to handle password changes and token refresh?
Don't try to implement your own authentication infrastructure. Chances you'll get a secure implementation are minimal and now you'll have to maintain all that code also.
Better use a authorization server from a reputable origin, like Thinktecture IdentityServer or Azure Active Directory and use standard libraries and protocols.
Some problems I see with your proposal:
if you do not sign the access token, what prevents me from changing
the claims inside?
if you need the user's password to validate the refresh token, you must store it in a way that you can retrieve it in clear text. Passwords should only be stored as a salted hash preventing you from getting to the clear text.
I'm using DRF, and I've enabled Session Authentication so that I can view the browseable API in my browser. In my mobile app, i'm using token authentication. I'm just curious, how does session authentication differ from token authentication in this context? It seems to me that they are more or less the same because with session based auth, a session id instead of a token id is stored in a cookie and used in the same way. Can anybody explain it better?
Sessions and cookies are mainly meant for browsers where the browser will take care of sending the cookie with every request to the server. This why the CSRF protection is only enabled by default for session authentication. On the other hand, token authentication will most probably used with non-browser clients where it stores the auth token and send it with each request in header. This token is not necessarily obtained by exchanging the credentials for a token similar to what happens in session authentication. There can be a use case where an admin generates these tokens and hands it to some other system client that will invoke your API, and clearly this client does not have to have a username and password to exchange it for a token.