From an implementation standpoint, SendGrid's event webhook signature verification is easier to implement than OAuth2. I'm tempted to just do signature verification, and skip OAuth2.
What is the purpose of both? Why isn't signature verification good enough? It verifies that the sender knows the secret private key. What value does OAuth2 add?
Related
Integrating one of my application with with SAML 2.0 single sign on. Using Okta provider for this. I came to the point where I receive base64 encoded "SAML response token" after successful authetication in okta and redirected back to my application. Within this token I see all the user details I need but here comes my question. Do I need to verify that response any futher or shall I just trust what I receice? Considering this token also contains signarure?
My idea for security would be to reach Okta again and verify if this was really issued by Okta. Not sure if this is even possible.
Using NodeJS for verification.
If by SAML response token you mean the samlp:Response issued according to the Web Browser Passsive SSO profile then then response contains an assertion and the assertion is signed by the Identity Provider (additionally, the whole response can also be signed).
There's a critical security requirement to always validate the response signature. This is mentioned in the SAML specs, section 4.1.4.3
The reason for this is as follows: in the Web Browser SSO Profile the token is returned by the Identity Provider in a web page that contains a simple form with SAMLResponse and RelayState fields and a bit of code that just autoPOSTs this form to your app. Technically, this means that for a short time the token is controlled by the user's web browser and this is where the token can be altered (or forged).
Thus, the protocol security heavily relies on the token's integrity which is achieved with the crypto signature - it's just a plain old XMLDSig signature applied to the SAML.
Your goal, as a token receiver is not only to validate the signature but also check the signature's certificate and compare it to the certificate you expect from the trusted provider (or a list of certificates of trusted providers).
Skipping this step makes your application vulnerable:
skipping the verification means users can alter the token (add/create/delete) claims to the assertion, the signature verification would fail but you skip it
skipping certificate matching against known certificate means users can forge their own assertions, sign it using a dummy certificate and present to your application. The signature verification step would succeed but you won't be aware that a dummy certificate was used to sign the assertion
If you don't want to do the proper token validation on a backend (don't blame you, it's a pain), then switch to OIDC. That's a better fit for authentication and authorization for the frontend.
If, however, the SAML response is sent to and handled by a backend, and some other token is being forwarded to your application, then you should evaluate what the requirement for the validation of that token is.
What isn't clear in your question is where in the user flow we're talking about, hence the number of comments on my answer.
I'm receiving a JWT from Microsoft Azure, and I need to verify it on my server. The JWT is signed using RS256, i.e. using asymmetrical private/public key encryption.
I know that various libraries exist that can be used to verify a JWT signature directly from our backend server. But I'm curious if it wouldn't be possible to verify the JWT signature using an online service? Since it's using RS256 and not HS256, only public keys are involved in the verification process, no private keys or other secrets.
It seems like it would be simple to put up a REST service that can take an asymmetrically signed JWT, verify the signature and give back true/false. But when Googling I can't find any such services. Not even from big names in the JWT-world, like Auth0.
Why is that? Is there some security concern with letting another server verify the JWT signature?
As we know the JWT is signed with secret key so the token itself can not be tampered but the payload we send to resource server with JWT can be plain text/json/xml/query string so how can we protect payload from tampering?
The signature is exactly what prevents the payload from being tampered. The payload cannot be modified without invalidating the signature.
Let me also clarify that JSON Web Token (JWT) is an open standard that defines a compact and self-contained way for securely transmitting information between parties as a JSON object. JWT is a generic name for the following types of token:
JSON Web Signature (JWS): The payload is encoded and signed so the integrity of the claims can be verified.
JSON Web Encryption (JWE): They payload is encrypted so the claims are hidden from other parties.
If you intend to prevent the payload from being tampered, then use JWS. If you want to hide the payload from other parties, then use JWE.
tl;dr To keep your payload (and token in general) safe all you need to do is use a strong secret and signing algorithm and verify the signature before trusting the contents.
JWT is signed with secret key, but the payload can be plain text/json/xml/query
You seem to be confused on what a JWT is. There is no separate JWT and payload, one is part of the other. JWT consists of Header, Payload and Signature. Signature is created over both - the header and payload parts and additionally your secret key. This means that if either piece is tampered with the signature can not be verified.
From JWT introduction:
Do note that for signed tokens this information [header and payload], though protected against tampering, is readable by anyone. Do not put secret information in the payload or header elements of a JWT unless it is encrypted.
To see for yourself you can use JWT debugger. When you change the decoded header or payload their base64 values change and therefore the signature changes with them. If you were to copy-paste the old signature value into new JWT it will show invalid signature error.
Unfortunately, there is no standard way to ensure that the request body has not been tampered during the transport using http headers.
AFAIK and among all the authentication schemes listed by the IANA, none of them have such feature.
However if your project is limited to a few number of clients or if you provide a detailed documentation, you can implement your own request signature mechanism.
I recommend you to read more about the following initiatives. Theses ones could help you in that implementation:
AWS Signature Version 4: certainly the most interesting resource. It also allows POST (maybe PUT and PATCH) requests to be signed
Hawk: same as above. Not widely used though.
OAuth 2.0 Message Authentication Code (MAC) Tokens. This one is abandonned and do not ensure the body has not been modified.
JWT by itself is not tamper proof. To make it secure, it must be transformed with these 2 steps:
Sign with Sender's private key
Encrypt with Receiver's public key
Signing with sender's private key ensures that any unauthorized modification of token can be detected.
Encrypting with Receiver's public key will ensure that the token achieves secrecy and only the intended receiver can see the token content.
JWT signed by Sender is called JWS.
Encrypted JWS is called JWE.
More information:
https://dzone.com/articles/securing-spring-boot-microservices-with-json-web-t
I think that https://jwt.io/ does not explain very well why or when to use JWT. It explains other things that could be ok to consider but not critical to decide whether or not to use it or why it will be handy.
My thoughts of why should we use JSON Web Tokens:
Authentication: It is useful to store the session outside the service and benefits from the stateless pros (E.g: scaling).
So JWT will be handy to not have to implement a remote session solution that will demand for example a memcached infrastructure, a token manager software module to create, renew, invalidate token. But it will have the drawback that the session information will be in the client and therefore exposed.
What is not clear:
Information Exchange: Share your secret (or a public key) in order to allow the sender to sign the token. Why not use https for this or certificates?
Ease of client-side processing of the JWT on multiple platforms, especially mobile. But https://jwt.io/ does not explain why JWT is used at internet scale. (In my opinion is because of the stateless server).
So my question is: are my assumptions correct? I'm confused about when I would need to use jwt and the benefits over the current/actual solutions
You've covered the propaganda and marketing, now let's take a moment to realise what problems JWT solve.
What JWT is not
When you verify a token, you have checked that the token was well-formed only, you did not prove that the party presenting the token has any authz so JWT itself is not proof of Authz, it is proof that an identity authenticated itself and was verified to be who they claimed to be then - and the JWT was generated to represent claims that verified identity had at the time it was verified. These are claims, ergo when the JWT is presented and you checked that it was well-formed (by doing a verify check) the attributes are like saying;
I claim I have these authorisations, please authorise me
I.e. you must make sure these claims are valid!
There are default claims that have nothing to do with authz but they can tell you about how long the claimed authz should be trusted once authorised nbf and they can tell you that the authz claims apply when used for a specific purpose aud and the custom claims are where you might add application specific logic for authz that help you check permissions like group names of the user.
A JWT is
The goal is having a way to have trust in a system (party C) that assures identity and authorisation, to a party that requires these identity and authn to be trustworthy (the end-user Party A) so that they can make ACL or Authz decisions in their app (Party B).
The JWT is generated by Party C when they verify Party A is authentic. Party C is a company like Okta, Auth0, JumpCloud, Azure, GCP, Amazon (Cognito). If you issue JWT, you are not typically the same organisation as the user of the JWT.
If you are the application developer, and you need a system to provide Authz and ACL, you must have a good foundation of trustworty Identity that you know and trust has done the proper Authn checks, this is why JWT was designed.
So as the application developer you almost never need to generate a JWT, they only time you do is if your software is providing a 3rd party proof of an identity that you have checked the Authentication challenge-response for and you assure the 3rd party using the JWT you generated. An example of this is OIDC, where the identity provider is the OIDC producer that generate the JWT, and your application and your users consume the OIDC protocol and pass the JWT around to represent the identity and authn of the end-user.
So when you get any JWT you first make sure it is well-formed, then after you verify it is a valid structure you read the claims inside the JWT and apply application logic to do things with the claims, things like add your own authz and ACL logic. Because Authz can never be outsourced, it is business logic that is always 100% written into your application, and everytime you assume authz was performed by other means that is not your own code, you are actually assuming trust not assuming authz
you literally have 0% authz unless you wrote 100% of the authz logic
So JWT uses are contextual
Are you the JWT producer? therefore the purpose of the JWT you generated is to assure that you performed Authn and you assure consumers of the JWT the identity is authentic
Are you a JWT consumer? Then you must check the JWT was well-formed so the claims can be used, then you must treat the claims as claims and make sure they are verified for the use case the claims are intended in your app, and if you do not check the claims you are putting inherent trust in the requesters who presented the JWT.
If you process claims as-is and not make sure they are trustworthy, then the requester has complete control of what the app does, because the app puts blind trust and if you say you have permissions because it is in the JWT, then the app will trust you are allowed.
Fact is, a public key created the signature of a RSA/ECDSA signed JWT, a public key! so the verify proves it was well-formed when it was signed with a public key...
Do you still trust the JWT verify method?
I'm reading about JWT and I'm confused about why there's a signature:
JWT site
What is the purpose of the signature if it's just a hashed version of the header and payload?
Also, why not just use oAuth? Or whatever 2 factor auth uses?
The purpose of Oauth2 and JWT is different, so it is not possible to compare them directly
JWT is a compact way of representing claims to be transferred between two parties (JSON with digital signature).
OAuth2 is an authorization framework used by third party applications (websites, mobile apps) to access on resources on a resource server, without exposing user password. OAuth2 can use JWT as the exchanged token
JWT is self contained and does not need server sessions . The digital signature is performed with server private key and protects the content. Any alteration of the header, the payload or the signature will be detected by the server and reject the token.