I'm trying to find out if it is possible for ADFS to send two types of tokens on one authentication ?
We have external systems working with JWT tokens but also systems with SAML tokens. We like to receive a JWT token and SAML token as a response on one authentication request to ADFS.
I was reading up on the following: https://learn.microsoft.com/nl-nl/azure/active-directory/authentication/concept-mfa-howitworks but this seems to be consecutive means of authentication not what I'm looking for
No - it's either one or the other.
It's not an ADFS issue.
That behaviour is proscribed by the protocol.
Related
I want to use the "microservice architecture" https://www.jhipster.tech/api-gateway/ using:
my company OpenID connect provider to authenticate users from the frontend SPA
JWT for authorization (that is, JWT from the moment the user is authenticated)
I'm not sure how that's supposed to be configured, or even if it's possible at all...
There are many architectural decisions you have to take on designing full system. But if you are going to use OpenID Conenct then there are few common aspects.
First, as you have figured out you must have a OpenID Connect provider (IDP). You have several options. You may use your own IDP for this purpose. Or else your micro-services may be controlled by an API gateway (Looking at Hipster architecture it does have one) which have a built in IDP for this. Regardless, from your application endpoint, you must use id token to authenticate the end user.
Now going into micro-service consumption, I see two options you can use. If your api gateway builds security for all micro services, then gateway must do the authorization part based on access tokens. But if you are consuming micro-services directly (without interaction with a gateway) then each micro-service handle authorization individually. Both have pros and cons but it's up to you to investigate and decide.
To sum up, your SPA consume id token for end user authentication. Once authenticated, you consume micro-services using the access token (preferably a JWT as you say). Once a micro-service receive a request, it will authorise the request based on access token JWT. For this one must validate JWT claims, signature of it as well as can use token introspection against IDP which issued the token.
When you authenticate with an OIDC provider you get back an id token and if you specified scopes for an API you get back an access token so that client applications can make requests to protected resources on the end user's behalf. Typically the access token is also a JWT.
But what is to stop someone from spoofing one of these access tokens, and creating one and passing it to an API? I understand there are safeguards to prevent modification because the signature will be different than what any validation logic is expecting, but what if a malicious user created a brand new one manually? Especially because these tokens can be validated 'in place' by any API that requires an access token (not all API's use the introspection endpoint... especially with a JWT). I do understand there is metadata around the signing keys for JWT's from OpenID Connect providers and that it is available in the OIDC discovery document. For example, here is Google's JWK metadata. Given that you have signing information publicly available, and JWT access token's can be validated without any requests to the OIDC provider, how are JWT's secure? What is preventing a person from creating one and passing it as a bearer token to an API that requires an access token?
But what is to stop someone from spoofing one of these access tokens, and creating one and passing it to an API?
Spoofing and reconstruction of signature is nearly impossible without the private key (assuming you are using asymmetric signing algorithm like RS256) that used for signing the original JWT.
The JWK information available via OIDC discovery document only contains the public key.
Also Use HTTPS for authorization / token exchange to avoid token sniffing.
I'm struggling with setting up reliable and performant solution to communicate frontend with different microservices. I do not really now how to maintain (maybe not need) CSRF between my frontend and end services
Solutions stack: PHP, Laravel Passport, JWT, oAuth 2.0, Axios
Current approach:
Actually I've started up with approach from Laravel's passport
https://laravel.com/docs/5.4/passport#consuming-your-api-with-javascript
Using oAuth 2.0 to authorize user from website A to service B.
JWT token is returned for further communication.
Token is saved in cookie within website A
Once user is authorized website A uses JWT token to manage requests without additional to oAuth server, by sending JWT token as cookie using HTTP headers (withCredentials) to authorize user.
For each website A's request there was CSRF token created from service B since user is authorized and cookie could be applied by another unauthorized website to access service B. That was killing my performance since it has to retrieve CSRF for each request made. (that what I actually assume from laravel passport approach and need to create CSRF with JWT token - maybe that was mistake)
My concerns:
Regarding to of James Ward post:
http://www.jamesward.com/2013/05/13/securing-single-page-apps-and-rest-services
The easiest way to do authentication without risking CSRF
vulnerabilities is to simply avoid using cookies to identify the user.
Cookies themselves are not the cause of CSRF vulnerabilities. It’s
using the cookies on the server to validate a user that is the cause
of CSRF. Just putting an authentication token into a cookie doesn’t
mean it must be used as the mechanism to identify the user.
From my understanding setting JWT with website A's cookie with its domain set could not be accessed via any other site from outside. Since that there is no possible way to make request to service B without accessing JWT.
So do we really need CSRF then to secure potential attack to service B while using JWT?
If so, how could I achieve the best (in term of performant) way to generate CSRF through different services to be sure that communication would not be vulnerable for attack from different sites?
Any advice will be appreciated!
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.
What are the main difference between JWT (Json Web Token) and SAML?
Can you suggest me any examples of these with spring security?
Both SAML and JWT are security token formats that are not dependent on any programming language. SAML is the older format and is based on XML. It's used commonly in protocols like SAML-P, WS-Trust and WS-Federation (although not strictly required).
JWT (JSON Web Token) tokens are based on JSON and used in new authentication and authorization protocols like OpenID Connect and OAuth 2.0.
Both are are used for authentication and authorization, commonly used for Single Sign-On (SSO) solutions.
Security Assertion Markup Language (SAML,pronounced SAM-el) is an XML-based standard for exchanging authentication and authorization data between parties, i.e. IdP (Identity Provider) and a SP (Service Provider).
An IdP (Identity Provider) : authenticates users and provides to Service Providers an Authentication Assertion if successful. Identity providers offer User Authentication As A Service.
A SP (Service Provider): relies on the Identity Provider to authenticate users.
Term in SAML
Term in OAuth
Description
Client
Client
Example: A web browser
Identity Provider(IdP)
Authorization Server
Server that owns the user identities and credentials
Service Provider(SP)
Resource Server
The protected application
JSON Web Token (JWT, pronounced jot) is a ID Token based on JSON to pass user information as Header, Payload and Signature structure. https://jwt.io/
OpenID Connect(OIDC) is built on the OAuth 2.0 protocol and uses an additional JSON Web Token (JWT), called an ID token. This token is a compact and self-contained (i.e. piece of data that is able to function independently) authentication mechanism that uses a JSON object to encode claims that are signed and encrypted. JWT can be used to authenticate clients, pass information between parties, or to authenticate APIs.
Use case:
OIDC is specifically focused on user authentication and is widely used to enable user logins on consumer websites and mobile apps. for example Stackoverflow login with Google account.
SAML commonly used to help enterprise users sign in to multiple applications using a single login.
OIDC is a more modern, lightweight, and easier-to-use protocol compared to SAML, while SAML provides a more complete and complex solution for SSO and identity management in enterprise scenarios.
In addition, SAML is a protocol and a token format while JWT is only a token format.