I have been reading about JWT and I understand it has three parts namely, header, payload and signature.
I keep the hashing algorithm used in headers, basic information in a payload eg. name, age , role, expiry etc in payload and then both of these are base64 encoded and then hashed using the
algorithm specified in headers to obtain the JWT
I have a frontend where I can login using username and password.
The login request goes to a server which authenticates it and returns a JWT. Lets suppose the algo used is HS256 which is a symmetric key algorithm.
So the server will have the secret key using which the JWT will be generated.
As part fo login request's response, the browser will have the JWT.
Now this JWT could be tampered with on the way so before it is used, I should verify the authenticity of JWT.
To verify, I need the secret key.
Questions:
How do I get this secret key on the frontend?
The payload can keep any information about a user (Not any sensitive information eg. passwords). Since JWT can be tampered with on the way, is it not dangerous to use the payload information without verifying the JWT on frontend?
The server which receives the JWT is the one who verifies the token. If someone modified the token, verification will fail and access will be denied, as (hopefully) no one outside the server knows the secret and therefore can't create a valid token. If the client knows the secret, esp. in browser/js envrinoments and with symetric hashing algorithmns, it's a big security risk and someone could steal the secret and create a new token with a valid signature.
Any bearer token should only be used over HTTPS. And TLS, which secures the HTTPS connection has integrity checks built in to prevent modification in transit.
So there's no need to verify the token on the client side.
Also it' better to treat the JWT token as some opaque string. This allows the issuing server to encrypt its content without breaking your application.
As others have pointed out, the client should never be in possession of the signing key, because the client can never be trusted.
Now, if the token is signed with an asymmetric key, you could download the public key and verify the token without compromising the security of the system. There are JavaScript libraries out there that can do this, but there's no reason you should be doing this.
Related
We are testing our own OIDC-IDP with a commercial client. (We don't have access to the clients code.) After some tests, the client always returns
OpenID Connect token validation failed: Token signature invalid (ID_TOKEN)
The IDP is in the wild of the web, the client is in our own network with a SSL breaker in between. We have a test client, also in the WWW, which works fine.
My question is, which certificate does the OIDC-client use to verify the signature. Is it the certificate of the website of the IDP? If so could it be that the reason for this error, is the ssl-breaker replacing the original certificate?
Note about OIDC lingo
OpenId Provider (OP) is analogous to SAML2 IdP
Relying Party (RP) is analogous to SAML2 SP
I knew what you were referring to when you wrote "IdP" and "client", but I want to mention that you'll commonly see OP and RP used for OIDC documentation / discussions.
Context and suggestions
The commercial RP you're testing with states that signature verification of the ID Token (i.e. JWT) is failing. To specifically answer your question, no, it is not using the x509 cert from the OP website to verify the signature. The key the RP uses to verify signature will depend on whether you've configured your OP to sign ID Tokens using:
HS256 (symmetric key algorithm); or
RS256 (asymmetric key algorithm)
Please have a look at the accepted answer on this thread for context:
RS256 vs HS256: What's the difference?
In the former case (HS256), your OP signs the ID Token with a secret key. And your RP must verify the signature using that same secret key. (NB: as you probably know, it's important to keep this shared secret key safe and secure.) If this is your environment, perhaps the commercial RP has a configuration option that allows you to upload or copy/paste in the secret key.
In the latter case (RS256), your OP signs the ID Token with a private key, but your RP verifies the signature using its public key counterpart. If this is your environment, perhaps the commercial RP has a configuration option to specify "jwks_uri" and "kid". These refer to the URI that your public key is published to, and its key ID, respectively.
So, right now I'm building an API for third parties uses and I was reading about RS256 and HS256. What I understood was that diff between is that in the first one you use a public key to verify and a private key to sign, and the other one, use just one key.. So if you use RS256 if because you want to keep your secret key secure and want the client to verify the token, but what I don't understand why you would like to verify the token in the client? Because you do a post request to the server, then it sends you back a token and whenever you want to make an authorized request you just use that token and the server verifies it and let you continue if its ok. So, why you would like to verify the token in the client? I thought it was a backend's duty.
I think maybe I'm wrong in something, hope you help clear this. Thanks.
EDIT:
So, my question is, I know the differences between RS256 and HS256 but what I don't understand it's the flow of how is use it. Right now I'm developing a third party api, and I just need to return a token when the client ask for it and then in the request that needs it, just verify from the server if it's a valid token. From what I understand, RS256 it's used when you want to verify your token from the client, if that's right, someone can give me an example of when or why would you want to verify the token in the client?
Use RS256 when:
tokens are signed by a third party, usually an Identity Provider(e.g. oauth2/oidc), and you need to verify that the token has been issued by a trusted entity
tokens are signed by clients, usually to get access to an API, where clients have previously registered the public key
tokens are signed by a centralized authentication server in a SingleSignOn system and they are used to get access to several federated servers
tokens are used to transfer data between two parties, not neccesarily for authentication purposes, and the signature is used to ensure the identity of the signatory
Use HS256 when:
tokens are signed and validated by the same server
I've been reading and trying to comprehend the differences in browser side security. From what I gather, SSL is used to keep people from sniffing the traffic you send to the server. This allows you to send a password to a server in clear text...right? As long as you are in an SSL encrypted session you don't have to worry about hashing the password first or anything weird, just send it straight to the server along with the username. After the user authenticates you send them back a JWT and then all future requests to the server should include this JWT assuming they are trying to access a secured area. This allows the server to not even have to check the password, all the server does is verify the signature and that's all the server cares about. As long as the signature is verified you give the client whatever info they are requesting. Have I missed something?
You are correct. "This allows the server not to even have to check the password." Why would you have to check a password on each request?
A JWT is a means of verifying authentication. It is generated upon a successful authentication request and hence forth passed with each request to let the server know this user is authenticated.
It can be used to store arbitrary values such as user_id or api_key but they are not very secure so don't store any valuable information here.
Be wary though, if a plain JWT is intercepted by a third party, it can assume this user's session and possible data.
SSL is a lower level form of security, encrypting every request from and to the server to prevent interception and retains integrity.
SSL is achieved by (purchasing) an SSL certificate and installing it on your server. Basically an SSL certificate is a small data file that binds a cryptographic key to an 'organisation'. Once installed succesfully, HTTPS requests (on port 443 by default) are possible.
I have a client that initiates calls through a proxy that requires authentication.
The proxy sends a challenge to the client and the client responds with the credentials.
Is it possible to respond to the challenge without the password in cleartext?
The point is that I don't think storing the password in cleartext on the client is a good idea, especially in this case, since anyone that knows the password would be able to make calls using the account of another person.
I know that storing the hash of a password is okay on the authenticating side (the proxy in this example), but I never saw such thing on client side.
Thanks, Mickael
Generally, it won't be in clear text because the challenge will state MD5, e.g. (from RFC 3261):
Proxy-Authenticate: Digest realm="atlanta.com",
domain="sip:ss1.carrier.com", qop="auth",
nonce="f84f1cec41e6cbe5aea9c8e88d359",
opaque="", stale=FALSE, algorithm=MD5
If it doesn't say MD5, that's an issue with your proxy.
If you know the realm, you can store the first stage of the response with password as an MD5 hash, along with the username (use of nonce comes later). Otherwise you'd have to use a reversible form of encryption locally for it.
Sorry, It may be posible few things are repeated in my question.
I have gone through some documentation/discussion signing an API request and twitter signature documentation
As per the discussion here signing an API request With a signed request the password is kept safe and an attacker cannot use the information in the query to sign another request.
But for signature generation uses SHA-1 non reverting hash function.
My Question is:-
If signature used to authorizes /authenticate client request, how that signature used on server side to check and validate the user request?