I'm trying to validate a google jwt I got from the client, but most of the information I can find online is lacking.
For instance, this post on Stack Overflow:
From
https://developers.google.com/accounts/docs/OAuth2Login#validatinganidtoken
the recommended approach:
"we recommend that you retrieve Google’s public keys from
https://www.googleapis.com/oauth2/v1/certs and perform the validation
locally.
Since Google changes its public keys only infrequently (on the order
of once per day), you can cache them and, in the vast majority of
cases, perform local validation much more efficiently than by using
the TokenInfo endpoint. This requires retrieving and parsing
certificates, and making the appropriate crypto calls to check the
signature. Fortunately, there are well-debugged libraries available in
a wide variety of languages to accomplish this."
It isn't clear to me what I'm supposed to do to validate this jwt. Most of the information I can find about how to verify the signature says to use the x5c key from jwks, but Google's page, found through the discovery doc, excludes that key.
Validation of JWT is covered in the spec (RFC 7519, section 7.2). One of the steps is validation of a signature, it's covered in JSON Web Signature (JWS) spec (RFC 7515, section 5.2). Specifications are the law but to apply the law you should understand how most applications do it or should do it. That is covered in JWT - Best Current Practices (JWT BCP; draft 06)
You can read all of that and try to implement it on your own or you can use one of the client libraries Google provides for you where all of this is, well, also done for you.
Related
I know this question is not anything new, possibly already been discuss all over the internet.
I'm new to it but after some study, I agree that it is safe as anonymous could sniff the Token but unable to append anything on it. I'm planning to store JWT in HTML5Storage, and decode the payload for some in-sensitive information: DisplayName, email_address, and role_info and etc.
Here is my question, could anonymous sniff my JWT Token and act on-behalf of me?
If that is possible, how can I avoid that?
In short, JWT by itself is not safe it's just clear text. JWT in basic terms is a standard protocol for how information is defined otherwise known as claims passed between to parties. In combination with JWS (signature) and JWE (encyption) will make it secure. The over arching topic for this is JOSE - Javascript Object Signing and Encryption. Aside from reading the RFC themselves which you should refer to as well there are ton of information online without stating the obvious nor insulting your search abilities. Check out http://jose.readthedocs.io/en/latest/ (includes reference links to RFCs)
So to answer your question if signed and encrypted with industry secure standards in flight (over the wire) and at rest (ie: database) yes it's secure.
In terms of spoofing as you need to pre-cautions in areas of session jacking and/or token jacking and prevention against things like rainbow tables.
JOSE really is just a standard no matter what standard, what you are really asking is about best practices for security measures, you should refer to OWASP as well https://www.owasp.org/
Does that help clarify your question?
I feel silly even asking this question, but am at the limits of my understanding, and am hoping someone can provide some context.
I'm looking at the following (https://stormpath.com/blog/token-auth-for-java/) which states:
The access_token is what will be used by the browser in subsequent requests... The Authorization header is a standard header. No custom headers are required to use OAuth2. Rather than the type being Basic, in this case the type is Bearer. The access token is included directly after the Bearer keyword.
I'm in the process of building a website, for which I'll be coding both the back-end REST service, as well as the front-end browser client. Given this context, why do I need to follow any of the guidelines given above? Instead of using the access_token, Authorization and Bearer keywords, what's stopping me from using any keywords I like, or skipping the Bearer keyword entirely in the header? After all, as long as the front-end and back-end services both read/write the data in a consistent manner, shouldn't everything work fine?
Are the keywords and guidelines given above merely best-practice suggestions, to help others better understand your code/service? Are they analogous to coding-styles? Or is there any functional impact in not following the above guidelines?
Given this context, why do I need to follow any of the guidelines given above?
Because they are standardized specifications that everyone is meant to conform to if they want to interact with each other.
Instead of using the access_token, Authorization and Bearer keywords, what's stopping me from using any keywords I like, or skipping the Bearer keyword entirely in the header?
Nothing, except that it won't be OAuth anymore. It will be something custom that you created for yourself that noone else will understand how to use, unless you publish your own spec for it.
After all, as long as the front-end and back-end services both read/write the data in a consistent manner, shouldn't everything work fine?
Who is to say that you alone will ever write the only front-end? Or that the back-end will never move to another platform? Don't limit yourself to making something custom when there are open standards for this kind of stuff.
Are the keywords and guidelines given above merely best-practice suggestions, to help others better understand your code/service?
No. They are required protocol elements that help the client and server talk to each other in a standardized manner.
Authorization is a standard HTTP header used for authentication. It has a type so the client can specify what kind of authentication scheme it is using (Basic vs NTLM vs Bearer, etc). It is important for the client to specify the correct scheme being used, and for the server to handle only the schemes it recognizes.
Bearer is the type of authentication that OAuth uses in the Authorization header. access_token is a parameter of OAuth's Bearer authentication.
If you use the Authorization header (which you should), you must specify a type, as required by RFCs 2616 and 2617:
Authorization = "Authorization" ":" credentials
credentials = auth-scheme #auth-param
auth-scheme = token
auth-param = token "=" ( token | quoted-string )
So, in this case, Bearer is the auth-scheme and access_token is an auth-param.
Are they analogous to coding-styles?
No.
Or is there any functional impact in not following the above guidelines?
Yes. A client using your custom authentication system will not be able to authenticate on any server that follows the established specifications. Your server will not be able to authenticate any client that does not use your custom authentication system.
I'm attempting to implement the Client Credentials flow of OAuth 2.0 to secure a RESTful service, using Apache CXF (version 2.7.12).
My only client (for now) will be trusted to keep the key and secret confidential - I'm aware of the considerations around that.
My question is how I should store the client secret on the authorisation server. In my mind, the 'client secret' is effectively a password, and thus should be salted and hashed. However, CXF's AccessTokenService, which does the comparison between the stored secret and the value passed in on the request, only does a String.equals() comparison, and doesn't seem to give me any hook where I can provide a different mechanism.
This means that I would need to store the client secret in plain text in order to compare it against the plain text value from the request, without a slightly hacky alternative.
Am I missing some obvious functionality that would let me hash the incoming value before the comparison, or am I being overly-cautious with the client secret? Maybe I'm wrong to treat it like a password?
A sort-of answer, for people encountering this question in the future.
My approach was to create a very simple filter (as described here: http://cxf.apache.org/docs/jax-rs-filters.html), which manually creates a SecurityContext (https://cxf.apache.org/javadoc/latest/org/apache/cxf/security/SecurityContext.html), and adds it to the Message as it passes through the Filter.
This means that as the flow continues on to CXF's AccessTokenService, it's identified as already being authenticated.
I also asked a question on the CXF mailing list, and got a very prompt reply from a developer agreeing that he'd recently noticed this as a potential issue, and was looking into it. Within a few hours he'd committed a change which addressed it, and looked like it would have been an ideal solution. Unfortunately, I've still not found time to test it, as my solution works and gives me a bit of extra flexibility that's helpful for other requirements on my project.
I'm building an API and I want every request to contain a token. I found a pretty simple way to do this, but I am wondering if I'm missing any security implications.
The way I'm currently doing it is using authenticate_or_request_with_http_token. I use that to check the token within the header combined with the user's email within a request. If both are legitimate -- then go through with the request.
I am also enforcing https on every request. Is this enough for a secure app? If somebody intercepts the request they can just take the params and the headers and make requests on behalf of a user, but I figured that ssl should encode everything properly. Am I completely misunderstanding ssl as well as the rest of the way I built it?
I think you are basically right.
But the most secure way to do API auth is with something like hmac, where the token is actually generated specific to the specific request and the time, so even if someone does see the URL, they still can't even use it to replay the same API request, let alone make other requests.
http://rc3.org/2011/12/02/using-hmac-to-authenticate-web-service-requests/
For instance, Amazon uses an HMAC-based approach to their API's.
But I think your analysis is correct that in general, if you enforce https, nobody ought to be able to see the pass token clients include in the request. I can't explain why people use HMAC instead; maybe just because there are so so many things that can go wrong and lead to someone seeing the token even in request headers. Including several kinds of man-in-the-middle attacks which ought not to be possible, but if a slip-up somewhere else makes one possible, the HMAC-based approach will still, for instance, prevent a man-in-the-middle from modifying the request the client meant to send, before it reaches the server.
There is HMAC built into the ruby stdlib. Digest::HMAC in the stdlib tells you to use OpenSSL::HMAC instead, but OpenSSL::HMAC contains no docs at all, and Digest::HMAC at least includes some bare bones examples docs. It would be nice to have better docs, but together with the overview of HMAC linked above, you can probably figure out how to use the stdlib ruby hmac to implement your auth pretty easily. It does put a higher burden on the client though, to find an HMAC library in the language of their choice, and implement the hmac auth to your app's specifications (there are a couple choices in how you might incorporate hmac into actual auth flow).
I'm designing a Service Oriented Architecture, and I also do need an authentication service in order to recognize clients and allow them to access resources.
Actually I found two possible solutions:
sign each single request using a pubkey and privatekey
token-based authentication using pubkey and privatekey
I'm not assuming an oauth2 service since it would add too many overhead designing the system for my needs, instead I do prefer to adopt a simpler (but also strong) authentication solution.
So here I come with my AuthenticationService, that can either be queried by the client making the API request (obtaining a token to pass alongside the request) or be queried by each single API endpoint to perform a reverse check of the HMAC that signed the request to see if it matches (checking if the private key used to produce the HMAC was valid).
I can see the latest to be simpler for the final developer performing several operations, but it would also require more checks to validate the token and handle it's expiration...
What potential security issues could the token solution raise that the single-request HMAC doesn't? What do you prefer and, possibly, why?
At the end I finally designed an authentication service based on the same Amazon solution.
It requires users to sign each request using the private key. So the request will send an Authorization header with the value "PUBKEY:SIGNATURE", where the signature is a HMAC composed of any request data (it could be the request body itself) plus a timestamp, to be passed inside the Date header. This implementation is strong enough to avoid MITM and replay attacks.
For more info about this solution here is a great explanation that helped me a lot to understand the real implementation.
Hope this really help someone else in the world facing the same problem.