how can I encrypt or obfuscate user_name in JWT token? We failed a penetration test because it.
username in jwt token
These are some recommendations to help you pass the penetration testing :
as the UserID is shown in the Token , the attacker can't change it as the Token has it's own signature .
Use the User ID from the database instead of the username.
if the only option is to encrypt the User ID , then you can get the username encrypted/decrypted by a filter in the backend server .
Related
Given that I have an access token generated using password grant type from the auth server. Is it proper to store the userId inside the token so that when the resource server decrypts the token, it'll use the userId when querying to its own database to get, for example, all posts made by the user?
Short answer : yes it is valid to have a self contained access token. Typically this will come in form of a JWT. If this is the case, you can extract JWT's sub claim (sub) to get end user identifier.
On the other hand, if you have a opaque access token, you can introspect the token from token introspection endpoint of identity server. The response can have the optional subject (sub claim) which is the identity of end user.
Once you obtain user identifier either of way, it's up to your application to use it.
I have implemented Identity Server 4 with a password grant type flow. I would like to know if it is possible to implement a refresh token so the client does not have to resend the username and password when the auth token expires. If so, can I please have some documentation.
Thanks
Greg
According to the docs:
Refresh tokens are supported for the following flows: authorization code, hybrid and resource owner password credential flow. The clients needs to be explicitly authorized to request refresh tokens by setting AllowOfflineAccess to true
So in theory you should be able to implement it, by setting the required parameters.
Just as an FYI, there is something else. Again from the docs:
The resource owner password grant type allows to request tokens on behalf of a user by sending the user’s name and password to the token endpoint. This is so called “non-interactive” authentication and is generally not recommended.
So if you have the chance to use another grant type - I would advise you so. If not, the answer to your question is - yes, you can use refresh tokens with the Password grant type
I am learning about Token-based authentication with JSON Web Tokens and here is how I see it now for a mobile app, built with, e.g. Swift:
I can create an object inside the app using user input, like
{
username: "patrickbateman",
password: "ismyknifesharp",
role: "regular",
...
}
Then I can generate a JWT token from it with a library.
Then I send it to a supported API endpoint, like /api/contacts/list. Or do I have to send login/password as they are to authenticate?
Server somehow checks the token correctness. But how? Should this server-generated token be saved in the database and used as a key? Or do I have to generate the token on server each time I get a request from client and compare it to client token?
Get and manage all the data I need.
Here are my conclusions:
I don't need to send login/password pair to server to authenticate the user.
I need to send token each time I need to get auth-only data.
I should implement some algorithm that changes the generated token due to some factors, like time passing, so that to make tokens expirable.
I should send the token inside headers, but not necessarily, as it can be done inside the body of the JSON requests.
Are these conclusions correct? What's the way to check token that client sends?
My opinions:
We should not keep password of user on client. Client should post password to server when sign up/ sign in, and don't save it anywhere in client. Request should be https, and password should not be encrypted. We will encrypt password later at server side.
Server will generate a token for this user after user login successfully. The token will contain the expired date in itself. We will use the token to authenticate permission with server.
I think every request to API should provide the token, except the sign up / sign in/ forgot password requests.
Token should be put inside the header of request.
Server should allow client request a new token with the old token (maybe be expired)
And the answer for "How to server check the token from client?". There are many ways to do that. The way below is my current approach:
Server side generate a token, which is a encrypted string of a user info (such as token expired time, userid, role... of user) and a password (keep only on server side) with HMAC or RSA algorithms. When user submit a token, server can decrypt and get the user info, expired time without querying from database.
Anyway, this question does not relate with Swift tag.
I am wondering why https can protect username and password.
I have already read specification about oauth1.0 and part of oauth2.0.
In oauth2.0, we use https to pass key and secret.
As i know https is safe to transmit username and password.
But I think i can still do replay accacks.
In many websites, system just pass key and secret to authenticate user, but aftering learning oauth1.0, I think it is not secure.Now I am confused if i need a signature like oauth1.0 whenever authenticate user by http.
I want to use BaseCamp API in my ipad application. I will ask user to enter username and password but each request requires authentication token. Please tell me how to get user token having username and password of user.
Please help.