Does IdentityServer4 have CSRF protection out of the box or do we need to configure anything to enable/strengten it? I have seen "state" value passed around between /connect/authorize and /signin-oidc but I'm not sure if it's enough. We are using hybrid flow with no consent page(internal application) and ASP.NET MVC OIDC if it's important.
As required by the spec - IdentityServer echoes back the state parameter.
The real protection happens in the logic of the client library - e.g. the Microsoft OIDC middleware (which is a protected).
If you are building your own client library you have to build that logic yourself.
Related
I am trying to enable OIDC authN and authZ workflow for my spring-java-web application. Ideally I wanted to do it in a IDP agnostic way.i.e.This application could be integrated with only and any one of the Azure AD,OKTA,AWS SSO,Google-auth by deployment admin.And I want users to be redirected to whatever provider the application is integrated with.
With OIDC as a standard, my understanding is i should be able to write a OIDC auth processing filter that should work with any of the providers. The necessary config that varies per provider ( auth url,client id,secret,JWKS url to get the provider keys etc) will be passed to this filter/rest template as parameters.
Q.1 Is it possible to implement provider agnostic OIDC filter? Can someone give any pointers?
I am aware that Spring natively provides Oauth2 libraries/apis like AuthorizationCodeResourceDetails, OAuth2ClientAuthenticationProcessingFilter . However I do not see any OIDC native processing filter in built. Is there any?
I tried and understood the workflow as given in https://www.baeldung.com/spring-security-openid-connect .However when i try to tweak this code to make it work with Azure AD it fails. Thats because Azure AD requires
The response_type parameter must include id_token.
The request must include nonce parameter to be set in request.
AuthorizationCodeResourceDetails does not support such param. Given that OIDC is a common standard ,
Q-2. I fail to understand why every provider still has different requirements? Doesn't it defeat the purpose of OIDC . Infact I read that google throws error if you pass nonce
Q-3. Are there any spring native ways to configure these additional provider specific params like nonce , promt, additional response-type ,preferable with examples?
I think your problems with Spring Security OIDC are that you're using the legacy OAuth library (at least that's what the baeldung article is illustrating). OAuth2 and OIDC are part of Spring Security 5.x now and not a separate project. There's an OIDC client "login-client" in this example: https://github.com/jgrandja/oauth2-protocol-patterns that might show different. Yes, OIDC should allow you to swap providers in and out although not all OIDC providers will implement everything (e.g. discovery, etc.)
I've got 2 different .NET Core 2.2 MVC projects. I'm using IdentityServer4 for the token server, Azure B2C for the identity store.
The 1st MVC app is a normal MVC application, and I've got it working perfectly with the OIDC Hybrid flow.
The 2nd MVC app is an Angular 7 cli app, which serves up the index.html and houses the API that the app will be calling. The angular app will not call any other APIs directly (gateway pattern).
My questions are about the 2nd app - I'm trying to figure out the best way to set up the Angular app for security.
My understanding is: OIDC Implicit flow exposes exposes the access token on the browser. OIDC Hybrid flow does not expose the access token (at least when hitting the same web server - no CORS), because the web server (client) uses the back channel to obtain the access token, via the authorization code, and its never exposed to the browser.
QUESTION #1: Is my understanding of Implicit vs. Hybrid correct?
If my understanding is correct, I'd think the best way to go would be Hybrid flow even for the Angular app, but most samples I've seen for using OIDC with Angular involve the Implicit flow, and don't take advantage of the authorization code / backchannel. Avoiding having an access token on the browser seems like a big deal, like a worthy goal, but wondering why it doesn't seem to be done?
QUESTION #2: I'm serving up my Angular index.html from my MVC server - why can't I just use Hybrid flow to protect the index.html page, and keep the token on the backchannel?
Something tells me my understanding of all this isn't quite complete...
Your understanding is correct. You can protect your index.html. The only problem you will face that way is that it's not the default configuration for today. With your requirements, most likely you don't need any of oidc client libs at all, you can protect your (only) API with a (same-site, http-only) cookie (not a bearer token) and in your Angular guards just ensure that you are still logged in to your back (if not, redirect through a local MVC resource to involve server-side code into login procedure).
See this question, especially the comments and link below for further reference.
We had an web application that already using form-login provided by spring-security, say, ERP. Now we are considering make ERP as an oauth2 authorization server to authorize other internal services.
The ERP still serving its business and all access are required to be authorized, but doesn't based on access token so I think it is not an oauth2 client. It does NOT serve as an Resource Server, neither.
I have read many article about how to setup oauth2 authorization server and develop an application using it. According to this comment I feel it is possible to make ERP authorizing other services without explicit setup a standalone authorization server (it's our final goal but not now):
Within the context of OAuth2, we can break things up according to the component you're implementing:
Client app: it's likely that server based OAuth2 Client app already uses HttpSession and therefore it makes sense to use Spring Session and benefit from all the goodies it brings
Resource Server app: since this component provides a stateless API that's authenticated against using an Access Token as a bearer, the HttpSession is not used and therefore Spring Session isn't suitable as well
Authorization Server app: it's highly likely that this already uses HttpSession so similarly like with OAuth2 Client app, it makes sense to use Spring Session and benefit from all the goodies it brings
What I'm going to do is add the #EnableAuthorizationServer into config, but I have no idea what's the next step.
My question is can I convert an existing application into an authorization server while keeping its original service unchanged? Where and How should I start?
I just found it's not that hard to integrate OAuth2 into existing system, below is what I did to make it work.
In short: EnableAuthorizationServer won't break anything exists, but they don't coming from nothing, either.
When I put on the EnableAuthorizationServer, spring-security-oauth2 gives me following endpoing:
/oauth/authorize
/oauth/check_token
/oauth/token
/oauth/confirm_access
/oauth/error
Those endpoints provide necessary functions to make OAuth2 works, and I just need to apply access control onto those endpoints with existing form login mechanism (probable not the check_token one).
Since this system didn't act as resource-server role, the authorization part is done.
I am building a SPA (javascript) which will call WebAPI A (.net MVC API) and which in turn will call (server side) WebAPI B (.net MVC API).
All three entities are protected by ADFS4 (OAuth2). In my workflow I want WebAPI A to call WebAPI B on behalf of the user who has logged into the SPA.
In reading the various documentation by Microsoft I found that the scenario described in the following article applies best to my case:
https://learn.microsoft.com/en-us/windows-server/identity/ad-fs/development/ad-fs-on-behalf-of-authentication-in-windows-server
The article assumes that the client application can perform the authorization grand flow. Nevertheless in my case I am dealing with a SPA which should be using the implicit flow of OAuth2. In addition even if I wanted to use the authorization grand flow I would still need to do a POST on the token endpoint of ADFS from the SPA which is not possible as ADFS4 does not offer a way to add CORS headers. I could of course deploy a proxy in front of it and add the headers... I have not explored this option yet.
I found a solution to make this work but it seems more like a hack to me; The SPA during login requests two tokens (1 for WebAPI A and 1 for WebAPI B) from ADFS4. It passes both tokens to the WebAPI A which knows that the 2nd token is for accessing WebAPI B.
Does this solution seem correct? Should I be doing something differently?
Thank you!
PS:
1) SPA cannot accesss directly WebAPI B as it is accessible only internally.
2) Assume I have total control over development on all three entities.
it's not a good idea to use the authorization code flow for SPA application, because you have to really keep the secret key that can generate access_token, which is not secure in that case.
i suggest that you use the implicit flow for you spa application and between your servers use the authorization code flow, this way you are sure about security
I currently have the ability to host one and only one site (meaning under one domain). I will have a SPA front-end, Web Api resource, and then IdentityServer4 for security (utilizing AspNetCore Identity framework for user management).
Something feels "wrong" with this approach as a single hosted site architecture. I believe AspNet Identity creates an auth cookie once authenticated, and then IdentityServer would be serving up JWT tokens for my SPA to call my API.
Upon further reflection though, this seems misguided. The thing that seems off is that I believe my API calls will also have the auth cookie automatically attached along with the JWT token in the header because the API call will be requesting from the same domain as the auth cookie was generated. And so it seems I'm using two forms of authentication at once unnecessarily... thoughts?
In other words, when everything is running under one domain, is adding IdentityServer4 to an AspNetCore Identity-enabled application unnecessary? The one benefit to plumbing in IdentityServer4 would be to future proof the application if it were to ever be deployed separate from its Resource (Web Api), then you would have nothing but configuration to modify.