In context of jwt tokens the word bearer ist used. I cannot find a lot about bearer on Google. I was wondering where the terms comes from and what it stand for? And why is it prefixed?
why is it prefixed?
Because otherwise it would just be a bunch of random characters with no context whatsoever, other than knowing that it's some info for some type of authorization.
what it stand for?
That the one who bears the token has the authority to do whatever the token allows
where the terms comes from
Hopefully Lord of The Rings (https://en.wikipedia.org/wiki/One_Ring#Ring-bearers) but I doubt it ;) It's a standard English-language word
A "bearer" is simply "a person or thing that carries, upholds, or brings", according to dictionary.com. So, in the context of JWT (or SAML, etc.) tokens, the "bearer" is simply the person or entity that presents the token to the server or resource.
Related
I know that it was discussed widely but I can't sum on what I read.
Is it correct that JWT is put to HTTP headers without encoding? Only being signed on. So that's common practice that token data (claims) is open and only signature allows to check whether JWT is reliable. From the point of view of keeping details in secrete people rely on HTTS.
Correct?
I have a general question regarding JSON Web Token (JWT).
If the JWT is stolen from the client (say, it was stored as a cookie or the app's database) by hacking or physical access, it can be used to send to the server which the server will think it is the legitimate user. Is this correct?
Is there any common or standard practice to guard against this, for example, by sending the type of device/browser or some reference code together from the client and the server checks it matches additional data the JWT token was generated and stored with. (However, I read that the standard practice is not to store anything on the server.)
Please advise as I need to implement Java JWT (JJWT), RESTful Java Jersey and Google Web Toolkit. (I've been reading documentation such as this: [https://stormpath.com/blog/where-to-store-your-jwts-cookies-vs-html5-web-storage]).
Thank you!
Possesion of a JWT is the proof of authentication. An attacker who stoles a token can impersonate the user.
So, keep tokens secure:
use a TLS channel
add extra security measures depending on the type of storage. Cookies are vulnerable to CSRF attacks. use HttpOnly if you do not need to access token from javascript. LocalStorage is vulnerable to XSS attacks
set short expiration time on authentication tokens and require credentials if token is expired
Blacklisting is not useful because you won`t know that a JWT has been stolen. And its usage breaks stateleness, one of the advantages of JWT
Additionally is possible to add the IP the token, but consider the usage scenario because it can be problematic on mobile devices or systems behind a proxy
On the client you are building the JWT like:
byte[] key = getSignatureKey();
String jwt = Jwts.builder().setIssuer("myTestApplication")
.setSubject("myTest")
.setExpiration(expirationDate)
.put("scope", "testing")
.signWith(SignatureAlgorithm.HS256, key)
.compact();
On the server side you can verify the JWT in regards to the the key and the expiration date exp (and more i.e. creation date, issuer iss, audience aud):
String subject = "notMyToken";
try {
Jws jwtClaims = Jwts.parser().setSigningKey(key).parseClaimsJws(jwt);
subject = claims.getBody().getSubject();
//OK, we can trust this JWT
} catch (SignatureException e) {
//don't trust the JWT!
}
Stealing the JWT should be avoided by using SSL,...but if the JWT is stolen there would be the risk of replaying exactly this JWT - right. That's where jti comes in.
The jti (JWT ID) claim provides a unique identifier for the JWT. The
identifier value MUST be assigned in a manner that ensures that there
is a negligible probability that the same value will be accidentally
assigned to a different data object; if the application uses multiple
issuers, collisions MUST be prevented among values produced by
different issuers as well. The jti claim can be used to prevent the
JWT from being replayed. The jti value is a case-sensitive string. Use
of this claim is OPTIONAL.
With this identifier you could recognize if this ID was already sent (you have to blacklist it on the server side which somehow undermines the nature of JWT). Because you should use the expiration date you could clean the IDs if the expiration date leads to a SignatureException.
However, if the 'hacker' stole the JWT out of the database, as you wrote in the question, you have further problems beside the stolen JWT probably, because than the attacker could also steal other data etc.
Hope this helped a bit.
In the OpenID Connect spec the azp (authorized party) claim seems to have a contradiction.
In the ID token definition section 2 it says:
azp
OPTIONAL. Authorized party - the party to which the ID Token was issued. If present, it MUST contain the OAuth 2.0 Client ID of this party. This Claim is only needed when the ID Token has a single audience value and that audience is different than the authorized party. It MAY be included even when the authorized party is the same as the sole audience...
But in token validation section 3.1.3.7, one of the steps seems to say the opposite:
If the ID Token contains multiple audiences, the Client SHOULD verify that an azp Claim is present.
Could anyone shed some light on this apparent discrepancy? Only the second instance uses declaratory language, so I'm leaning towards favoring that in my implementation.
You're correct, the whole azp situation in OIDC is confusing. For what's it's worth, they have an open issue associated with it; see OIDC - Issue 973 (azp claim underspecified and overreaching).
From the definition of "aud" in JWT and its use in Connect's ID Token (relevant spec text is copied below), it seems that that the client id of the client/RP that made the authentication request has to be one of the values, or the only value, of the "aud" claim in the ID Token. That's logical and consistent and provides reliable and interoperable guidance to implementers about producing and consuming the ID Token. I think that the client id of the RP/client that made the authentication request should always be represented in the aud of the returned ID Token.
The text around "azp" in the ID Token section and the ID Token Validation section seems to maybe suggest something different, however. Like perhaps that the client id of the RP/client that made the authentication request could, in some totally unspecified circumstance, be the value of the azp claim and that the aud would not identify that client as an intended recipient. Am I misinterpreting things?
Personally, from the client application developer perspective, the best course of action seems to be honoring the ID Token validation rules which always imply that the value within azp will also be present as an aud. However, according to what's available online Google seemed to use it a bit differently so you could have a value in azp not listed within aud, so there may be situations where you play by Google rules and not (just) OIDC.
If you're implementing an OP a probably good option is also to entirely stay away from including azp in your issued tokens if possible or only include it when using multiple audiences with one of them being the value also in the azp.
I think the two sections are not conflicting each other on the concept level (a bit confusing on the wording though).
if there is a single audience which is different from azp, it makes senses to have both azp and audience to show that difference. In a multiple-audience case, at least one of the audiences will be different from azp and hence azp must be present to make it clear.
azp usually equals to client id (the application requests the token). audience of the token can be the app itself or another application which receives the token for validation.
Is it a good practice to save the csrf token in a cookie or is it better to use a hidden field in a form? Also is it good to regenerate csrf token every user request like what captchas are doing?
Thanks
It is best to include it in the form. The idea behind a CSRF token is that it is not passed passively (e.g. if a malicious user is able to trick the browser into accessing some URL that does something nasty). Cookies are passed passively.
The best explaination to this question can be found on OWASP website at OWASP CSRF Prevention Cheat Sheet page.
Firstly, using cookie for a CSRF token can not help much because all cookies, even the secret ones, will be submitted with every request. All authentication tokens will be submitted regardless of whether or not the end-user was tricked into submitting the request.
Secondly, the application can include hidden input parameter in the form with a common name such as "CSRFToken". The value of this token must be randomly generated such that it cannot be guessed by an attacker.
Furthermore, Challenge-Response is another defense option for CSRF. It can be implemented in following ways:
CAPTCHA
Re-Authentication (password)
One-time Token
The CSRF cookie is certainly open to attack but implementation safe as the session value will always be checked against a submitted token value either stored in the body or header of the request so I can't see a reason against. The double submit (http only cookie vs post data) or token synchronizer (session vs post data) patterns outlined on the OWASP website are good pratices and both use cookies.
Double submit as mentioned earlier moves the storage to the client so is considered stateless but either way two tokens for comparison, of which one always remains unknown to the attacker.
I am working on a REST API for a web application that up until now we have developed internally for a couple of companion applications. Now that we are looking at opening up to outside developers we want to add tokens to the API in order to help identify who is making requests and in general to help manage it's use. At this point we are using https and basic authentication for user authentication on the API.
The token scheme we've been discussing would be very simple where each developer would be assigned 1 or more tokens and these tokens would be passed as a parameter with each request.
My question is if you've done something similar before how did you do it (did you do more or less, how did you handle security, etc) and do you have any recommendations?
First, you might want look at http://OAuth.net. Depending on your usecases, it might provide the security you need.
As to the token, it's a BLOB to most protocols, including OAuth. You can put any information you need in it in any format.
Here is what we do,
First we assign each developer a key with associated secret.
The token itself is an encrypted name-value pairs. We put things like username, expiry, session id, roles etc in there. It's encrypted with our own secret so no one else can make it.
For easy of use with web API, we use the URL-safe version of Base64 so the token is always URL-safe.
Hope that helps!
You might also want to think about maybe adding a time based token that would allow you to limit the amount of time a request is valid. this will help with someone trying to do a replay attack.
You would have a handshake call to get/assign a time valid token based off the above developerKey. This token would be stored locally and passed back to the caller.
The developer would then use this key in a request to validate the request and the developer.
For example that key can then be used for 5 mins or for 10 requests or whatever you define. after that point the generated time based token is removed from the valid list and can no longer be used. the developer will then have to ask for a new token.
UUID is very good for any temporary random key you fancy dishing out. Unpredictable and fast to generate, with collisions so unlikely they are effectively unique. Make nice session keys also.