I have a SP(Service Provider implemented using Spring SAML), I want the SP will send the authentication SAML token to another service application .Now I need validate(only) the token against the IDP at service apilcation end. How can I achieve this?
Any help will be apreciated
There is no mechanism in the standard SAML profiles which allows validation of issued SAML assertions against IDP servers. Validation is typically done by recipients of the tokens - by validating XML signature on the assertion and verifying it was performed using a trusted certificate.
There are also additional standards which prescribe issuing and usage of SAML assertions for such use-cases, for example WS-Trust, but it tends to get complex pretty fast.
You might also want to look into OAuth 2.0 standard, which is a good way to achieve machine-to-machine authentication, performed on-behalf of a user.
Related
Is it really required to validate the access token by decrypting it using the public key? I am asking this question related to the Azure AD. I am understanding that the JWT token can be validated to make sure it was in deed signed by Azure AD. If this is the case, are there any Azure AD endpoints where I can pass the token and get a response whether it was signed by it? All the articles over the internet explains the manual way of grabbing the public key from Azure AD endpoint and then do the decrypt steps by ourselves. Are there any automated way to validate the access tokens?
It would be great if someone can throw light on whether its a standard practice for the APIs to validate the access tokens before servicing the request.
It is considered best security for APIs to validate JWT access tokens on every request. This approach is fast and scales to a microservices architecture, where Service A can forward the access token to Service B and so on.
The result can be termed a 'zero trust architecture', since both calls from internet clients and clients running within the back end involve digital verification before the API logic runs.
You are right that a certain amount of plumbing code is needed to verify JWTs. This is typically coded once in a filter and then you don't need to revisit it. For some examples in various technologies, see the Curity API Guides.
I can confirm that this approach works fine for Azure AD - please post back if you run into any specific problems.
Some Authorization Servers also support token validation via OAuth Introspection, but Azure AD does not support this currently.
Introspection is most commonly used with opaque access tokens (also unsupported by Azure). See the Phantom Token Approach for further details on this pattern.
Yes, you should validate it every time. The reason to use JWT is to authorize request. If you don't care who sent the request and it doesn't matter if it was a hacker or your customer than don't use jwt and oauth. If you do care and use it you have to be sure that the jwt was not changed by some hacker, so signature has to be checked.
I'm used to working with ADFS for a long time already and recenlty I was asked to do a proof of concept with Oauth2 on ADFS. Struggling through terminology I managed to set most things up, but still I do have some unanswered questions. Hope someone can shed some light on these...
For SAML / WS-Fed relying parties, it is possible to set custom web content, using Set-AdfsRelyingPartyWebContent. Is this also possible for web api relying parties created in an application group?
Would it be possible to add claims to a client authenticated with client_id / client_secret (server application in ADFS terms) when using the client credentials grant flow?
Even after setting the 'IssueOAuthRefreshTokensTo' 'AllDevices' on the web api application, I still don't receive refresh tokens. What am I missing here?
When posting a token issued by our ADFS on e.g. jwt.io I receive an 'signature validation' error. How can we resolve that?
We would like to set an audience for the access tokens, so applications can use the audience instead of using the appid to verify if they can consume the token. Can we modify the audience?
What does add-adfsclient do? Does it create a client_id, which can then be linked to a relying party (with Grant-AdfsApplicationPermission), thus enabling OAuth2 for an existing relying party?
When configuring a ad user principal for a server application and use 'password' as grant_type with the client credentials grant flow, I cannot seem to find the correct syntax, as ADFS always give the error 'MSIS9622: Client authentication failed. Please verify the credential provided for client authentication is valid.'. I have used the syntax 'user#fqdn' for the username.
Thanks you for helping me out here!
Let me try and work through these.
In ADFS, OIDC applications and WS-Fed / SAML RP are completely different. You can't mix and match.
jwt.io has a signature error because it doesn't know the .well-known endpoint to get the key. Refer this.
To get extra claims you need to add an API as that is the only place for claims rules.
To get a refresh token, you need a scope of "offline_access".
For resource owner password, user name and password are separate fields. Refer here.
Feel free to ask more questions. Just expand your question.
Also, samples here. Look at the menu on the LHS.
Update
What do you mean by "can modify web content on a per relying party basis"?
Re. jwt.io, read this.
For refresh tokens, read this. It seems ADFS doesn't follow the spec here.
I have been reading about OpenId Connect and their flows that are implicit flow, authorization code flow and hybrid flow.
I know that for example, the implicit flow is kind of insecure and should be used just in public clients like SPA application.
Now I´m trying to understand the Hybrid Flow that can be used for non-public applications like .Net MVC applications where you have a backchannel communication and thus you can save a secret password.
Reading about the Hybrid flow I know that it has 3 different types of response_type that can be:
code id_token
code token
code id_token token
For me, the best response_type would be code id_token where I can get the code in the front channel and then send that code to the Identity Server Provider and get the access token through the backchannel.
I've been searching for information on a real-world application of response_type=code id_token token, or code token, but other than reading that in these flows the first token/s are issued by the authorization endpoint which is the front channel and the final tokens that are issued by exchanging the authorization code are issued at the token endpoint, which is the backchannel and thus inherently accepted as being more secure, I fail to understand what you would use this for. Any information would be gladly accepted.
Why hybrid flow? The oft-documented rationale is that your app can immediately have info about the user via the id_token while the access token acquisition is still in flight. Technically this is true but it's still rarely used in the wild.
One real-world example is a Financial-grade API (FAPI) profile developed by a working group under the umbrella of OpenID Foundation. It recommends hybrid flow for security reasons. It's worth noting that the channel split "feature" of the flow is not enough on its own to provide the desired security properties, more "cooperation" from other moving parts is needed. From FAPI implementer's draft part 2:
This profile describes security provisions for the server and client
that are appropriate for Financial-grade APIs by defining the measures
to mitigate:
attacks that leverage the weak binding of endpoints in [RFC6749] (e.g. malicious endpoint attacks, IdP mix-up attacks),
attacks that modify authorization requests and responses unprotected in [RFC6749] by leveraging OpenID Connect's Hybrid Flow that returns
an ID Token in the authorization response.
and details
8.3.3 Identity provider (IdP) mix-up attack
In this attack, the client has
registered multiple IdPs and one of them is a rogue IdP that returns
the same client_id that belongs to one of the honest IdPs. When a user
clicks on a malicious link or visits a compromised site, an
authorization request is sent to the rogue IdP. The rogue IdP then
redirects the client to the honest IdP that has the same client_id. If
the user is already logged on at the honest IdP, then the
authentication may be skipped and a code is generated and returned to
the client. Since the client was interacting with the rogue IdP, the
code is sent to the rogue IdP's token endpoint. At the point, the
attacker has a valid code that can be exchanged for an access token at
the honest IdP.
This is mitigated by the use of OpenID Connect Hybrid Flow in which
the honest IdP's issuer identifier is included as the value of iss.
The client then sends the code to the token endpoint that is
associated with the issuer identifier thus it will not get to the
attacker.
8.4.3. Authorization response parameter injection attack
This attack occurs when the victim and attacker use the same relying party client.
The attacker is somehow able to capture the authorization code and
state from the victim's authorization response and uses them in his
own authorization response.
This can be mitigated by using OpenID Connect Hybrid Flow where the
c_hash, at_hash, and s_hash can be used to verify the validity of the
authorization code, access token, and state parameters. The server can
verify that the state is the same as what was stored in the browser
session at the time of the authorization request.
For a more technical description of these two attacks and countermeasures, see Single Sign-On Security – An Evaluation of OpenID Connect
For a realllly detailed description, take a look at OIDC Security Analysis paper.
The hybrid flow allows the backend to continue to act on the user’s behalf in an offline way (when the user is no longer present sending requests by browser) or independently of the frontend... doing other stuff in parallel. It can use the back channel exchanged refresh token to continue to get a new access token and work indefinitely.
i'm implementing a REST layer for an existing application. I have my userid and passwords stored in database and i would like to authenticate these credentials while calling my REST services. Note that this is a standalone application.
After investigation, I figured out 2 ways.
Basic implementation with HTTPS - this approach makes sure that
userid and password passed is not tampered by Man in middle attack.
Using Authentication Token(JWT) - user initially passes his userid
and password and server gives back an Authentication token.Once user
have an authentication token that could be used for subsequent
request.
Using OAuth 2.0 - I'm very confused in this approach. After reading the docs and specification, I found that since my application
is standalone, I need to implement Authorization Server, Resource
Server etc.
I'm asked to implement OAuth here, but i'm not convinced that OAuth is required in this scenario. I'm more inclined towards just implementing JWT(tokens)
Is OAuth really mandated in this scenario. What i understand about OAuth is it is used when you already have a service like Facebook/ Google.
Could someone pls confirm if my train of thoughts are correct and if OAuth 2.0 is required in this case?
The primary goal of OAuth 2.0 is to allow users to authenticate to use a client application via a third-party authentication provider (e.g. Google, Facebook, etc.), without exposing their credentials (typically a username/password) to the client.
In your case, if users are only ever going to authenticate to your system using their credentials in your database, then implementing OAuth 2.0 doesn't add any substantial value for you.
The OAuth 2.0 specification does define a "Resource Owner Password Credentials grant", intended for legacy use cases, that would apply to your situation: a user sends credentials, and you return an access token (that could be a JWT, if you like). If it's desirable from a management or marketing perspective, you could implement the Resource Owner Password Credentials grant and legitimately state that your application "conforms to a subset of OAuth2, as defined by RFC6749".
I am working on a mobile application that uses an api built with ASP.NET web api framework. We decided to use ACS alongside a custm STS as a mechanism to secure the api.
We are using a custom STS because we need to authenticate users against our own identity store.
The information flow is as follows:
Mobile app calls the custom STS with user credentials.
User is authenticated against our own identity store.
Once user is authenticated an authorization code is retrieved from ACS and used to retrieve an SWT access token.
Token is returned to mobile app.
Mobile app embeds access token in authorization header and fires request to API
HTTP module in API validates the access token and data is returned if the token is valid.
Everything is done over SSL as we are using oAuth 2.0.
The problem with oAUth 2.0 is that it is at risk from man-in-the-middle attack as the SWT token issued by ACS is a raw token and not encrypted in any way. It is however, signed using a 256bit symmetric key.
We are using swt tokens because we are using an http based approach and the token fits nicely into the auth header of an http request.
Microsoft have provided some ACS security guidelines in the following post:
http://msdn.microsoft.com/en-us/library/windowsazure/gg185962.aspx
we currently implement 2 of these as we check the issuer and the audience i.e that the token was issued by our trusted issuer (ACS) and that the token was issued for the correct audience (our api).
our scenario is based on the following article:
http://msdn.microsoft.com/en-us/library/hh446531.aspx
as such WIF is not used to handle incoming tokens. WIF is only used in claims processing.
given the above mentioned scenario is there anything else that we could be doing to improve the implementation we have to secure our rest based api?
any and all comments/criticism/suggestions welcome.
Thank you.
I think you're already taking the correct approach. The most important thing is to verify if the token is signed by ACS. Never share your ACS secret key with anyone else. If they don't know the key, they cannot forge the signature.
Also do not store confidential information in the token (such as password, credit card number, etc.). You should expect the token may be obtained by someone else, but no one can forge a token with the correct signature.