I have a DashboardApi and an EnterpriseApi on my system. May be one more later.
I am new at IdentityServer3 and I wonder solve my problem.
IdentityServer saves client applications that will use an api. So I have 2 or 3 api. Will I create IdentityServer for all api? Because DashboardApi will consume EnterpriseApi. EnterpriseApi will consume another api.
And users will login to Dashboard application. I could not imagine the organisation.
To answer the question: you may have one instance of IdentityServer being your identity provider/authority across different "resource" APIs as long as they all point back to that same authority when it comes to token validation.
Then an access token used for "DashboardApi" can be used by "EnterpriseApi". It is important to proxy the token properly and in my experience it would be advantageous to create different scopes for each API to have better access as to which calls may be used to proxy into the second API through the first (especially if user consent is a concern).
Related
Assume my company is offering 2 applications, say Mail and Calendar.
Both applications are using OAuth 2 to secure access.
Now Calendar wants to access data from Mail. If those were applications from two different vendors it would be natural for Calendar to ask the user to authorize it's access to Mail etc.
But since the applications come from the same source I'd like them to be able to share data without the user having to explicitly give permissions.
Or to put it differently: I have ID/Access/Refresh tokens for Calendar. How can I exchange them for an Access Token for Mail without bothering the user?
How can this be done in OAuth 2? I control both the applications and the Identity Provider.
The only solution that comes to my mind is for both Mail and Calendar to be the same Application, but that doesn't seem right (and has other issues, e.g. if you want to restrict someone's access to one of them). I could also implement special access outside of OAuth 2 but that is even worse.
A real world example would be Gmail and Google Calendar. They both present OAuth 2 interface to the outside world, but you don't have to allow them to talk to each other.
PS. References to white papers or cases studies would be appreciated
SEPARATED CLIENTS
By default in OAuth you would register multiple clients which get their own tokens. You would then use Single Sign On when navigating between them the first time:
Client ID: app1
Scope: openid scope1
Redirect URI: https://app1.mycompany.com
Client ID: app2
Scope: openid scope2
Redirect URI: https://app2.mycompany.com
If user consent is involved the user has more choice this way of how they grant access to their personal assets.
COMBINED CLIENT
You could potentially combine these into a single entry like this. Note that there is usually a hosting prerequisite of a single base domain in order for token / cookie storage to work:
Client ID: combinedapp
Scope: openid scope1 scope2
Redirect URIs: [https://app1.mycompany.com https://app2.mycompany.com]
PROS AND CONS
The first option is cleanest most of the time, since you avoid tokens with access to too much data. The second option can make sense for related micro-UIs that are really a single app with the same permissions.
APIs AND SCOPES
To share data across apps, companies build API endpoints. You can then have multiple apps that each use scopes representing multiple business areas. See the Scope Best Practices article as a starting point for designing authorization. Eg user logs into calendar app with scopes openid calendar mail - and therefore can get mail data also.
I've got a SPA application which gives statistics and information to anonymous users. It is a react spa app and will consume backend REST Web API(.net core). These data are not specific to users, therefore the information is freely available and no user authentication is required. However, I don't want my Backend Api layer to be exposed to the internet (i.e not use by anonymous applications such as postman, rest clients, etc). I'm familiar with the Client credential flow (OAuth) but I can't use it for this application because there is no concept for user login in this application.
What would be my best options that limit access to my API layer to anonymous applications (i.e postman, etc), or is it not possible at all?
You can't use client credentials flow for your SPA. Anyone would be able to download your SPA, extract the client id and secret and use it to call your API.
If you do not want to authenticate your users, there's no good way to protect your API. Move your SPA to a traditional web application hosted on a server to protect it using client credentials flow.
It's not possible to make an API accessible to a public client (your SPA) without also making it accessible to users making API calls from Postman or custom code. It's possible to do the reverse, only because of the limitations that browsers put in place.
Depending on what you're trying to achieve, you could use something like reCAPTCHA to validate that the users of your API are humans, not scripts. That along with human-scale rate limiting would probably filter out most of non-app users.
OAuth 2.0 protocol provides permissions delegation of a user so that third-party apps can operate on its behalf. A typical way this is done on the OAuth flow is requesting a user consent to either approve or deny access for the app (Okta example). Here is an official spec describing how it works in general concepts.
I'm looking for the standardized approach to perform the same flow but for the user groups (e.g. organizations). GitHub does that in some way for organizations, so it looks like organizations represent just a group of user accounts. Are there any standardized approaches to this problem?
If not maybe there are any recommended ways how its typically done architecturally or can fit into OAuth 2.0/OpenID Connect protocols.
The OAuth 2.0/OpenID Connect protocols do not cover how access control is performed.
You can, within the OAuth 2.0/OpenID Connect protocols, pass OAuth Scopes or use the OIDC user info endpoint data to allow the resource server to make determination for Access Control.
Many of the commercial products within this area allow the use of LDAP as a back-end for authentication and will even convert LDAP Groups to Scopes.
I would assume, but I do not know, that GtHub stores data with a link (like a group) for the on Organization and/or the user. I know GitHub exposes this using OAuth Scopes.
Oh, and the OAuth Spec is at: https://oauth.net/2/
But if you require Authentication of users then you need to be using OpenID Connect which is built on-top of OAuth 2.0.
Remember that "OAuth 2.0 is NOT an Authentication protocol"
-jim
There are limits to what you can show on the consent screen and dynamically calculated data is not usually supported.
You ought to be able to express a high level scope that you can present to the user though.
In terms of authorizing based on a user's organisations the claims caching technique here can be useful:
https://authguidance.com/2017/10/03/api-tokens-claims/
That is:
* Use OAuth for user identification and high level checks
" Then do the real Authorization based on your back end data
I'm making some assumptions here, but I believe the issue arises from trying to authenticate two things at once.
If the organization is what you need, then go ahead and create a flow to authenticate the organization as the principal subject (via a user who has access to it), instead of actually authenticating the user itself.
Once the access token is generated, you do not necessarily need to know which user generated it anymore (or at least, the token itself does not need to know). If your user needs to be able to view and/or revoke access tokens, they should still be able to do that, since they have access to the organization in your app.
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 would like to offer authenticated API access to my web app. The consumers of such a service are typically other web sites/services.
What would be the best method of authenticating these users? OAuth, openID, http authentication?
As so much in our line of work, the answer to "which is best?" is "it depends." :)
HTTP Authentication - If you're already letting clients log in to your service via an ID and password, you'll probably only have to do minimal work to get this to play nicely with your API. If your API is basically mono-purpose and doesn't require detailed permissions, you can get something working fairly quickly here.
API Token - If you want clients to be able to authenticate easily without providing a password (think companies that build a service that interacts with your API; maybe the IT dept. doesn't want the dev. team knowing the passwords; etc.), then attaching a random API token à la GitHub to the user account is probably the quickest way to go. As a bonus, you can supply a method for regenerating the API token without having to change the account password.
OAuth - If you have multiple permissions or want finer-grained control over how and when a client can access your API, OAuth is a pretty good bet (OAuth2 is much easier to work with, IMO, and supports multiple methods of obtaining an access token). Furthermore, many languages have libraries, gems, etc. that will allow them to simplify the OAuth workflow.
I would say the "best" method is oAuth. It's more flexible and it can be application independant for further uses .
I am using oAuth to authenticate my clients (applications).
;)