Trying to decide on which auth model to use. I have a cloud-based multi-tenant ERP app. These tenants will want to give access to some of their APIs to another one of our fat-client ERP systems and (potentially) other 3rd parties. Higher ups said no way should the OA client know a user and password. Conceptually this smells to me as "Auth Code", EXCEPT I am not sure how you can have a redirect_uri when the OA client is a fat-client.
Related
It seemed like client_credentials flow was appropriate for a machine-to-machine communication between our system and third parties for importing and exporting data.
But if I have two third parties p and q say and users on our system u and v say, then I need to know which of p and q can acces the data of which of u and v.
For example: user u grants access to p (but not to q) and v to q (but not p).
I can give different client secrets to p and q but when they present thir secret to IdentityServer in order to obtain a token I need to know which of p and q it is and add a claim to the token that my controllers can use to determine which of u ad v's data is visible.
I can implement ICustomTokenRequestValidator to intercept the secret and look it up in the configuration context, but the Id column is not in the model class, so I could abuse the Description column as a foreign key to my table of third parties -- seems hacky.
Is there a standard/recommended way to resolve this situation -- that different machines have different data visible to them (different claims in their token)?
If you use client_credentials flow then there is no user-interaction involved.
Each third party should have it's own client with corresponding client credentials. Do not share the same credentials over boundaries, i.e. between different third parties. By having separate clients for separate parties, you minimize the security risk and minimize the impact when having to revoke or change the credentials.
With that said, in the Client Credentials flow the Authorization Server returns a token if the request is valid - it does not know from the request if the user authorized the request or not because the user is not involved. But it authenticates the client. So, if you want to differentiate between several third parties, give them individual clients. If you can't add a claim to the token.
Scopes and claims are the tools to define what a client requests to do. Some authorization can be done in the Authorization Server. For example, an Authorization Server typically only allows a client to request certain scopes.
Use then claims (the data in the token) for a fine grained authorization in the API. It depends on your use case. If the API is supposed to return a filtered result, i.e. only return data from users that are ok with it, then the API needs to be able to look this information up somewhere, as #gary-archer states. Use an applicable claim from the token that enables the API to identify the client or third party. It can then use this data for the lookup. For example, use the client_id claim but it really depends on the Authorization Server which claims it adds to the token.
If the client already knows beforehand which user's data it is going to access, it could add the user-id when requesting the token and - once again - depending on the capabilities of the Authorization Server - get a token with a user_id in the claim set. Then the API can use the client_id and user_id for a lookup.
How you collect the users' consent is out of scope and happens out of bound. It's part of your business logic.
At the end it is all about designing the token. Here is another article on Centralizing Identity Data
The standard option here is to include custom claims from your business data at the time of token issuance. Rather than machine to machine I would describe your scenario as B2B.
EXAMPLE USE CASE
Consider an API called by business partners who act as suppliers of inventory to your system. In this case a useful access token might look like this, and is what I would aim for:
{
client_id: 1hvf367g
supplier_id: 42
exp: ...
}
API requests for stock items could then authorize based on the supplier_id value in the access token. Eg by running a SQL query on the business data, filtering on the supplier ID. All of this keeps your API code simple.
DATA MAPPING
For this to work you need to design onboarding. Eg a button click to create a supplier in your system might create the OAuth client using Identity Server, then save the client_id to a suppliers table in the business data.
Not all identity systems support issuing custom claims in the above manner. An alternative design is to just include the client_id in the access token, and look up the supplier ID from business data when your API receives an access token. This tends to add complexity to API code though.
SUMMARY
I think your question is really about designing business permissions, and OAuth alone cannot solve it. If I'm right then the Claims Best Practices article may be useful.
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.
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.
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