I need to implement SSO in my JAVA Web App with OpenID Connect. I already have experience in SSO with SAML 2.0 with WSO2 as Identity Provider.
I am clear on the client part, and planning to implement the same with Spring Security.
My question is, does it make sense to build my own Identity provider for OpenID Connect? For some reasons, I do not want to use any third party IDP (like WSO2).
If yes, is there any library that can help? If no, what are the best IDP I can use for OpenIDConnect? Ofcourse, WSO2 is on top of my list because I have already implemented SAML SSO with WSO2 and it also supports OpenID connect.
Any experience or suggestion is most welcome.
An answer for this question is not that straightforward. But I will try to summarise some key points which will be helpful in making a decision.
Implementing in-house identity provider
Cost and effort
You will have to develop and maintain everything by yourself. This means implementing the specification (OpenID Connect) adhering to RFC6749. Adding to that you need to register clients, issue tokens, validate tokens and maintain token state (ex- issued refresh token). Indeed some libraries like Nimbus would come in handy.
If you are dealing with third parties you are bound to strictly follow specifications. And it could be a higher development cost and effort depending on the talent pool
Maintenance and support
Any internal development will come with support and maintenance. Bug fixes, issues and new feature requirements will be costly over time and could involve valuable developer time
Performance and reliability
As you have mentioned, implementing your own identity provider and making it to perform as any existing product is challenging. Besides, identity provider should be reliable. It must be secure enough to sustain security attacks (specially if you are exposing it to internet). And implementation should be done with security in mind from ground up (ex:- Secure certificates for token signing, access token and refresh token entropy)
Using a third party product
Cost and effort
Depending on the provider, it could be free and open source or paid tool. And if it is an established product there will be less implementation effort
Maintenance and support
Now this depends on the service agreement. You might have to pay for support. But you get rid of maintenance. A product might lack some features you expect it to have (ex- RFC7662 - token introspection endpoint). For example MS Azure AD lacks an introspection endpoint.
Performance and reliability
Given that it's a product you purchase or available openly and used by many, commercial products tend to have optimum performance. And indeed they are developed by domain experts (ex:- A dedicated team who have gone through all the specs) and could include higher reliability.
P.S -
Regardless of all of these considerations, there could be a requirement to develop and maintain an internal identity provider. If that's the case you have to implement it according to related specifications and make it secure. Hope this helped with your decision.
Related
I understand that there is a bit of an overlap between OAuth, OIDC and SAML. Especially if I understand right, Authentication is provided by both OIDC and SAML to achieve SSO.
However, my question is from a developer's perspective.
Is OAuth relatively easier to develop and maintain than SAML? Both as Identity provider and as a consumer.
Is any one of them more prone to bugs or hazzles than the other one?
With respect to user experience which one is more easier to setup with your enterprise Identity provider, "in general" ?
Finally, is there a recommended option when you as a consumer want to provide SSO? OIDC or SAML?
Just so you do not confuse this question to be yet another "SAML vs OIDC" : Say you want to provide SSO to your product via Azure AD, G-Suite or Okta etc. All of which support both OIDC and SAML, then would you go with OIDC or SAML?
OAuth is for authorization. OIDC and SAML are for authentication.
Whichever you choose, I would strongly recommend not implementing this yourself. Instead, choose an open-source or commercial product with a good track record. You don't want to be responsible for security weaknesses etc.
The choice of OIDC vs SAML often comes down to what's supported by third party sites you wish to SSO to. If this is purely internal, you may decide to use OIDC. If this is for SSO to third parties, you may decide to use SAML as this is much more commonly used in the corporate world.
I am creating a new React SPA. Users of a legacy app need be able to use the new app without re-authenticating. So I need to support SSO.
It's important to note that it is also required that users of other (currently unspecified) apps should also be able to use the new app without re-authenticating, so whatever approach I take needs to be sufficiently decoupled to potentially allow this.
The legacy app supports authentication via Shibboleth, the new app currently has no authentication method, but uses JWT for authorisation.
I'm wondering if anyone has any experience of such a scenario? It seems to me that I probably need to be create an OAuth2 authorisation server for the new app to talk to and I need to somehow bring Shibboleth into the mix for the authentication, maybe with the authorisation service acting as a Shibboleth Service Provider. Googling around hasn't revealed much useful info.
Is what I've described along the right lines? I know it's very high level and woolly, but I'm really not sure of the approach to take. Any advice, information or experience in this area would be gratefully received!
GOALS
It's a little bit of a subjective question, but the main goals are usually as follows:
Focus on building your UI and API security in a future facing manner
Also provide good Login Usability
Also deliver on non functional requirements such as availability / reliability
AUTHORIZATION SERVER
On the first point, the modern option is to integrate UIs and APIs with an Authorization Server - perhaps as in My Tutorial. Your architecture is then good, but the migration is not trivial.
FEDERATING TO SHIBBOLETH
The Authorization Server can then redirect to Shibboleth and talk SAML2.0 to achieve Single Sign On, as you suggest. It is a complex solution though, and may be a backwards step in some ways.
AVAILABILITY
This is usually a big concern, and most companies use a cloud provider such as Azure / AWS due to its high availability / low maintenance / low cost. Would this be a better option for you?
I've read a lot about the different flows (authorization code, implicit, hybrid and some extensions such as PKCE). Now I'm on the authorization code flow with PKCE.
PKCE ensures the initiator is the same user as the users who exchanges the authorization code for an access token. That is nice and OK.
When using this flow without a client_secret (which is recommended for SPA/Javscript applications) there is no warranty that the client is the known/original client. So, the 'consent' the user gave, is of no value. uhh?
I am working on a nativate client (a public downloadable binary). A secret cannot be considered confidential when baked in the binary, it can be decompiled for example.
Now I'm in dubio. What is better, bake the secret in the binary so that there is some extra layer of assurance the client is the known client or stop asking for 'consent' and give the same client_id to the whole world, only relying on the user-credentials.
Or is there something wrong with my story?
Very good question and made me realise a gap in my understanding. It is the role of the redirect uri to deal with this risk. In the web / https case the only hack that could work would be to edit the hosts file of the user. I'm the native case it is less perfect and your question is covered below. Generally our best bet is to follow recommendations / standards - but they have plenty of problems! https://web-in-security.blogspot.com/2017/01/pkce-what-cannot-be-protected.html?m=1
To others reading this case I've read a lot more.
Client impersonation is not easy fixable.
RFC8252 seems to be the most applicable article with recommendations for native apps - https://www.rfc-editor.org/rfc/rfc8252
"Claimed ‘https’ scheme" is mentioned as the best solution (IOS, Android and maybe UWP apps).
Since I'm working on a native Windows, non-UWP application I can't use this. As far as I can see the "Web Authentication Broker based on the app SID" is possible for my situation.
The other method is to accept the client as not known/identified and ask for 'consent' every time the client would access personal data.
I have an application that uses personal access token to access to GET the list of items. I want to switch to using OAuth, the application will use ITEMS_READ only.
My application is a daemon running on an instance of secure Ubuntu server dedicated to this application(s). Regarding the "application server" is there anything that square recommends - what are typical best practices with the "application server"?
Thank you
The API documentation is fairly extensive, and includes a helpful section about OAuth. A few common pitfalls I've noticed with OAuth implementations in the past lead me to call these things out:
If you are only building a one-off integration for your own use, it is probably not worth using OAuth.
Make sure you understand how OAuth works. If you find yourself asking for users' client secrets or personal access tokens, or anything else that requires them to open the app management dashboard at connect.squareup.com, you need to rethink your implementation. Only you, the developer, should need to understand access tokens and other API credentials.
You can generally ask for more OAuth scopes than the bare minimum that you need. I'd recommend getting MERCHANT_PROFILE_READ as well. That can be useful to manage accounts, and so you can hit /v1/me to get various IDs you'll need.
The Square OAuth access tokens expire as described here. They last for thirty days, so this can tend to creep up on developers who aren't aware of it. You will need to use a scheduled task to renew access tokens that are about to expire and purge your old tokens after doing so. Something as simple as a cronjob should be fine.
In terms of the technology stack you use, that's entirely up to you. The Square Connect team is happy to help and provide recommendations when we can.
I am exploring the possibility of using OAuth 2.0 in future projects.
What I see is that OAuth is built on the concept of [Resource Owner]+[Web Site Client]+[Authorization Server]+[Resource Server]. A lot of the articles and tutorials in the internet talks about using Facebook, Twitter, etc. as the Authorization/Resource Server, which is all cool and good.
What I am struggling to mentally picture is if I am the one who is going to create my own Auth/Resource servers, why will I choose to go this way? What are the scenarios that otherwise may not be ordinarily be achieved through ASP.NET MVCs form based authentication and the [Authorization] attribute model?
Take a look at the RFC 6749 - it talks about usecases. Its good comprehensible RFC.
Usecase verbatim from RFC:
o Third-party applications are required to store the resource
owner's credentials for future use, typically a password in
clear-text.
o Servers are required to support password authentication, despite
the security weaknesses inherent in passwords.
o Third-party applications gain overly broad access to the resource
owner's protected resources, leaving resource owners without any
ability to restrict duration or access to a limited subset of
resources.
o Resource owners cannot revoke access to an individual third party
without revoking access to all third parties, and must do so by
changing the third party's password.
o Compromise of any third-party application results in compromise of
the end-user's password and all of the data protected by that
password.
Read Aaron's article - OAuth2-Simplified
Recently I learnt OAuth with help of Apigee,you can use anything like google API.
Here is my github project oauth20_apigee if it helps checkout.
It depends on what your short and long term goals are going to be. In my opinion, the short and dirty points are:
OAuth 2.0 is typically used to grant an application access to specific resources on behalf of the user which is a great mechanism for allowing 3rd party applications extend your product. So if you're building an API, then this would be great for you.
Likewise, it is beneficial in that it not only enables someone else to extend your product, but you can also extend theirs. For instance, you could create a trusted application for another product, they could link their customer directly to your module (for lack of a better term) without requiring a separate login, provided you support their token format (typically through the use of a federated identity provider)
If you build your application to support 3rd party OAuth authentication, you can improve the user's experience for registering with your site. By allowing them to use their choice of authentication (e.g. google, facebook, twitter, etc), they won't have to enter in a lot of personal information for umpteen millionth time. You just need to take their authentication and collect any additional information you need. Then create an internal account for them and associate their provider with their account
You can emulate single sign on through the use of a federated IDP, again, enhancing the user experience. For instance, if the user is already logged into google, your product can accept the token and simply request additional scope be added to the token without the user having to sign in again.
Implementing your own OAuth provider is a different beast and I'm not sure there's a ton of benefit to it unless you're planning on being the next Facebook or something.
I think there is a lot to gain from using OAuth. I believe that enabling these credentials in your web sites provides a significant advantage because millions of users already have accounts with these external providers. These users may be more inclined to sign up for your site if they do not have to create and remember a new set of credentials. Also, after a user has logged in through one of these providers, you can incorporate social operations from the provider.
However there is always the devils advocate and this article explains why OAuth could be a possible sercurity hole in an application if not implemented correctly:
http://www.thread-safe.com/2012/01/problem-with-oauth-for-authentication.html