Are there any major security drawbacks to using Self-Issued Providers with OpenID Connect? (And the Implicit flow that those imply/require?)
As opposed to, say, using Dynamic Client Registration?
We're working on a project that requires decentralized cross-domain authentication, where server/client pre-registration is difficult or impossible. Which means we need to pick one of those two mechanisms, it sounds like? (Self-Issued Providers or Dynamic Client Registration). Which of those is more appropriate for what sort of situation?
Self-issued providers and Dynamic Client Registration are serving different purposes.
Self-issued providers are self-hosted or possibly in-browser OpenID Connect Providers that would not have a trust relationship with Relying Parties. They provide the equivalent of self-registration to RPs and provide "non-asserted" identity.
Dynamic Client Registration lets Clients/RPs register themselves with OpenID Connect Providers to dynamically create a trust relationship so that the Provider can provide 3rd-party asserted identity to the Client.
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.
Our business use case is that we have four to five services deployed as java spring web applications. These services have user/customers derived from either registration process or some existing running applications exposed as rest services. We intend to make a single portal which provides users to be able to use a single account / credential to log into many services directly.
With internal approach we assume having individual customer table for each services. And a common Login table for all services whose id is tagged/mapped as foreign key in individual customer table of each services.
Also some services can be accessed without registration , in that case we fetch the data via customers account id from some third rest service and store it in individual services/application customer table and in common Login Table if not already present.
For services which require registration we store the customer credentials in login table if not present; and also in service/applications customer table with a common login table mapping.
But we need a secure portal with session tracking , session timeout just like Single Sign On
With some research we have narrowed the approach to implement the above scenario with either SSO or Oauth2 which her is applicable.
Refer the link (https://stormpath.com/blog/oauth-is-not-sso ) for more insight.
Can someone suggest which approach SSO or Oauth2 is applicable for our business usecase ?
if SSO , which is the best opensource simple SSO for java Spring applications?
if OAuth2 , what will act as Client application, Authorization Server , Resource Owner and Resource Server? As we have services(Java applications) as client application hosted in Common Application/Portal? will the common login table act as resource owner ?
You will likely want SpingSAML. If the applications are hosted on separate paths, like example.org/app1 and example.org/app2 then you could use a Shibboleth Service Provider as the SAML SP for the applications.
You'll still need an Identity Provider of some sort, which SpingSAML can't do, but there are innumerable IdP implementations out there: i.e. Shibboleth Identity Provider, ADFS, or a commercial IdP like Okta, OneLogin, Ping, etc.
We are developing an application in a microservice architecture, which implements signle sign-on using Spring Cloud OAuth2 on multiple OAuth2 providers like Google and Facebook. We are also developing our own authorization server, and will be integrated on next release.
Now, on our microservices, which are resource servers, I would like to know how to handle multiple token-info-uri or user-info-uri to multiple authorization servers (e.g. for Facebook or Google).
This type of situation is generally solved by having a middle-man; a single entity that your resource servers trust and that can be used to normalize any possible differences that surface from the fact that users may authenticate with distinct providers. This is sometimes referred to as a federation provider.
Auth0 is a good example on this kind of implementation. Disclosure: I'm an Auth0 engineer.
Auth0 sits between your app and the identity provider that authenticates your users. Through this level of abstraction, Auth0 keeps your app isolated from any changes to and idiosyncrasies of each provider's implementation.
(emphasis is mine)
It's not that your resource servers can't technically trust more than one authorization server, it's just that moving that logic out of the individual resource servers into a central location will make it more manageable and decoupled.
Also have in mind that authentication and authorization are different things although we are used to seeing them together. If you're going to implement your own authorization server, you should make that the central point that can:
handle multiple types of authentication providers
provide a normalized view of the user profile to downstream resource servers
provide the access tokens that can be used by your client application to make authorized requests to your microservices
I am developing a WebAPI over my already existant MVC application, using the OAuth2 authorization system.
This API will allow my clients to request my users information. Currently, my users are stored in the Identity tables (ASPNetUsers). In my application, they are registering, logging in, etc... with the help of the Identity classes and methods.
The problem is here : I want to manage my API clients accounts, in an "Identity way", so I can authenticate them when they ask for Access Tokens. But I can't use the current users tables, as there is no common points between my clients and my users.
The perfect solution would be to have two Identity tables : one for my users, and one for my clients, but after my long-time searches, I figured it was not possible, or it would be a mess, at best.
I would not use ASP.NET Identity as a way to manage OAuth2 registered client applications. Even though some client applications (confidential) are indeed issued client credentials that's probably the only thing they share with a username/password user identity. It's a completely different thing and as such it should be managed and stored independently.
If you're thinking that this sounds like a lot of work, you're absolutely right. It isn't trivial to implement a custom username/password authentication that proves secure and implementing an OAuth2 authorization server is many times as complex.
If you really want/need to go that route then some mandatory reading:
The OAuth 2.0 Authorization Framework
OAuth 2.0 Threat Model and Security Considerations
JSON Web Token (JWT) (assuming you choose JWT as token format)
If you're still evaluating all your options I would also consider the possibility of delegating all the authentication/authorization work onto a third-party, Auth0 comes to mind, but I'm biased because I work there.
What is the difference between Claims based authentication vs What is provided by OAuth.
I am looking for conceptual difference and not technical difference. When do I choose Claims over OAuth and vice versa.
Claims based authentication is proposed by Microsoft and build on top of WS-Security. But OAuth is more a open source protocol that is being proposed to allow fetching resources from different portals based on a security token.
Claims also has this concept of token (SAML encoded or X509 certificates).
I am trying to understand when do I choose Claims over OAuth and vice versa.
Thanks
Claims-based identity is a way of decoupling your application code from the specifics of identity protocols (such as SAML, Kerberos, WS-Security, etc). It is not only for web applications and is implemented as a .NET library / framework called WIF.
OAuth is a specific protocol by which one web site can obtain user consent to access their private data on another web site.
It is not really the case that you would choose one or the other, in fact they are complementary. Potentially you could use both at once, if you were building a .NET web app that performed OAuth via the WIF.