I am trying to understand IdentityServer3 and different terms associated with it in order to secure my Web APIs. Can someone explain what is significance of Scope in IdentityServer with some good example.
I found this link but idea is not clear.
Thanks in advance!
Scope
It's safe to say that Scope is kind of a role to access a specific set of resources IMHO. IdentityServer has two scope types, the ScopeType enum is defined and described as 'OpenID Connect scope types.'
Identity Scope : representing identity data (e.g. profile or email)
For example, if you have a profile identity scope, then clients with this scope can get the profile data from an identity provider ( e.g. IdentityServer )
Resource Scope : representing a resource (e.g. a web api)
For example, if clients have a calendar resource scope, then they can call a /get/calendar/months web api and get the resources.
Scope will be included in Claim when a HTTP request with an access token is in flight and will be further validated at the validation stage for the access token.
Of course the client should be added prior to running IdentityServer and proper scopes should be specified in AllowedScopes; a member of the Client class in IdentityServer.
The better resource to know about oAuth2 is IETF, and about OpenID Connect is openid.net.
IdentityServer is an implementation of OAuth2 and OpenID so it's documentation will not cover the basics that related to OAuth2 and OpenID.
To understand first about scopes you should have a clear understanding about clients.
Client: Models an OpenID Connect or OAuth2 clients (not your client application) and it should have a clear flow for example you defined a client which uses implicit flow.
The flow is the way that you should follow in order to get the needed data for example access_token and id_token.
All flows can be used with any cases but there are recommended flows for every case.
For example, up until now, it was recommended that you use implicit flow with native and javascript clients. Though, recently this has been changed to Authorization Code with PKCE. See Identity Server's blog post on this change to IETF/OpenID recommendations
Scopes: Models an OpenID Connect (Identity scopes like email, given_name etc.) or OAuth2 (Resource scopes like your WebApi that you want to protect it's data) scopes.
You can think about scopes as intent of the client, for example: The Client ask you to use your resource owner to grant me access to your openid scopes > given_name, email & prefered_username and your OAuth2 scope > WebApi.
For full understanding:
1- Pluralsight - Building and Securing a RESTful API for Multiple Clients in ASP.NET
2- Pluralsight - OAuth2 and OpenID Connect Strategies for Angular and ASP.NET
Related
I have a RESTful API that is consumed by a browser frontend and multiple machine-to-machine clients. So I'm issuing tokens with Keycloak 18 through Standard Flow (Authorization code) and Service Account Flow (Client credentials).
The operations on the API's resources are protected by scopes like read:resourceA, update:resourceA, read:resourceB, etc.
When I assign a Realm Role to a Client Scope, and if I map a user to the same Realm Role, the tokens issued through the Authorization Code Flow (browser frontend) contain the scope.
Also, when I create a Machine-to-Machine client and I add to Client Scope directly to the Client, the tokens for the M2M client also contain the scope.
So far so good. But as soon as I try to do both at the same time, I no longer have the scope in tokens issued by the M2M-client.
It seems that adding a Client Scope to a Role makes it impossible to use that scope otherwise.
The obvious, but bad solution would be to create a second set of scopes for this kind of client. Is there any other solution I'm not aware of?
I'm migrating from Auth0.com to Keycloak, and that's currently the only point blocking me from finishing this migration.
Thanks,
Pascal
In a standards based approach, scopes are composed of claims. Scopes are fixed at design time, whereas claims have runtime values. So at runtime a particular client and user may result in these values:
- myscope
- roles: [user, admin]
- subscription-level: gold
An example is the built-in profile scope, which includes name and email claims, and might look like this at runtime:
- profile
- name: John Doe
- email: john#doe.io
It is recommended to avoid scope explosion, as you suggest. In Keycloak I would keep scopes the same for all clients, so that nothing changes in the client interface.
A realm role is a type of claim, though a Keycloak specific concept I think. Perhaps you can represent it differently, or configure a realm role for the M2M client also?
It turns out that I missed the concept of Service Account Roles. For all those running into the same troubles:
How to add a new Role to an Authorization code flow client
Create client with Default Flow enabled
Create client role
In Client Scope Settings, add the new client role to the scope
In Client Settings, add the scope(s) to the list of default scopes
Add the new client role to the user
How to add a new M2M client
Create the new client
Create a new client role in the Client settings
In the Client settings, in the tab Service Account Roles, assign the new Client Role
In the Client scope settings, assign the new client role
In Client Settings, add the scope(s) to the list of default scopes
As far as I understand, applications that we can login with our different accounts use OpenID Connect(A profile of OAuth2.0).
OAuth is for Authorization and OIDC is for authentication(It has ID Token-User Info Endpoint).
So, was it not possible to login to an application from another application account using OAuth before OIDC? (If possible, how?)
If plain OAuth can't be used for authentication, what is/was it used for?
I mean what does it do with 'authorization' exactly?
What does it get from the resource service with the access token?
I have always found the jargon around this unhelpful so I understand your confusion. Here is a plain English summary:
OAuth 2.0
Before OIDC apps used OAuth 2.0 to get tokens, and this involved optional user consent. The process of getting tokens was termed 'delegation'.
In practical terms though all real world OAuth 2.0 providers also included authentication in order for their system to be secure. How authentication was done is not defined in OAuth specifications.
OAuth is primarily about protecting data, where scopes and claims are the mechanisms. These links provide further info:
IAM Primer
Scope Best Practices
Claims Best Practices
OIDC
This just adds some clearer definition around how authentication messages before and after authentication should work:
A client simply includes an openid scope to use OpenID Connect
A client may force a login during a redirect via a prompt=login parameter
A client may request an authentication method via an acr_values parameter
The client receives an ID token (assertion) once authentication is complete, can digitally verify it if required, then use the information in it (eg a user name)
OIDC still does not define how the actual authentication works though.
Use them together
Pretty much all OAuth secured apps (and libraries) these days use both together, so that the authentication and delegation both use standards based solutions. It gives you the best application features and design patterns for doing the security well.
I'm developing an authentication/authorization system in Node Js for a microservice based application.
I read some articles and documentation about the OAuth2 standard but I need some clarification for my use case.
Basically OAuth2 has some actors like:
Resource owner (user)
Client app (a web application in some OAuth2 grant flows like authorization code, implicit, password)
Authorization server
Resource server (service I want to access to)
So in my database I store a client (web application) with its client_id and client_secret.
Let's suppose that one of my microservice needs to access data from another microservice. Both of them espose a REST Api.
There is no interaction with user, all is done in the background. In this case I would use the client credential flow.
Following OAuth2 rules, both of them are resource servers but in the same time it looks like they are client apps as well.
So should I register them in the client DB table/collection with client id, secret etcetera or did I make some mistakes?
Thank you
If I understood your question correctly, the caller micro-service is your client and the one that is being called is your resource. A lot depends on what type of micro-service communication pattern have you implemented. If you are implementing an "API Gateway" pattern, then your Gateway is always client and all other micro-services can be treated as resources. But if your micro-services can call each other then like you mentioned each one of them have to be registered as client and resource at the same time.
In most OAuth2 typical use cases, the scope is used by resource owner password grant type, or authorization code flow, where a user login is required.
It seems that scope is mainly used to control access of users' resource. For example, to authorize a 3rd party client to access the resource owner (user) resource at another server.
In some cases, user is not present. For example, a company wants to provide a API for another company only. Client credential is being used. Most API gateway products have subscriber management option to control which client ID can access which APIs. In that case, is it still meaningful to use OAuth scopes to manage access to APIs? Why?
Besides, I cannot find any examples using scopes along with client-credential grant type. Is it rare use case?
The Client Credentials grant type is used to access protected resources that both sides own/control/trust.
Scopes are supported by this grant type. They are typically not used because the trust is already there and limiting that trust via scopes is not required.
In other words, the reason that scopes are not used is that if the trust is not there, other grant types are more appropriate.
My needs:
Let's consider 2 end-users of the same domain.
User UA is the resource owner of resource RA.
User UA wants to delegate access of resource RA to end-user UB.
My main OAuth 2.0 interest comes from total token control (revocation at any time, etc.).
OAuth 2.0 Framework allows a client to act on the behalf of a resource owner with it's explicit permissions.
Oauth 2.0 defines resource owner and client roles (see the roles section) where:
Resource owner can be an end-user (that can grant access to a protected resource).
Client is an application making protected resource requests on behalf of the resource owner.
In the spec, the client is always considered as an application (with no particular implementation characteristics).
I would like to know if it is ok to implement OAuth 2.0 with an end-user as the client role or am I abusing OAuth completely?
My intuition is that OAuth 2.0 is only designed for third party application (with interoperability) and not for 2 end-users of the same domain. Am I right? In the other hand all the token mechanism really fits my needs.
PS: This expired OAuth specification (2010) talks about delegating authorization by a Resource Owner to another user via a Client using the OAuth protocol. But it's not that relevant.
I would like to know if it is ok to implement OAuth 2.0 with an
end-user as the client role or am I abusing OAuth completely?
Well, it is only an opinion of mine, but if, say, a Buffer can represent me posting my contents to Facebook using OAuth, why my friend Jack (a human, not robot) can't?
Of course, you must think it all over, especially in terms of security. But the abstract scheme looks fine by me.