The examples provided in rfc7644 and rfc7643, the URL's of different resources are in the format,
http://<domain>/v2/<Resource_Name>
One of my requirements is to use URL's like, /v2/x/a/resource1 , /v2/x/b/resource2 and to be the resources of the same type.
Does SCIM protocol offer this kind of flexibility?
But found the usage of this URL GET /api/scim/v2/groups/:group_path/Users here
If by resource1 and resource2 you mean users and groups endpoint, then no. You supposed to provide base URL to IDP to be used for every endpoint (User, Groups).
So your base URL has to look like:
https://yourscimdomain:/scim/v2///
and IDP will add to the end of it Users or Groups endpoint.
Related
I want to implement a solution where having 2 apis which take data from one another restrict access to the exposed endpoints by scopes.
Let's say that api1 exposes two scopes. read-only and write-only. some of its endpoints will allow only one out of the two some will allow both. Same for api2.
What I don't understand is where are the scopes validated ? Or to be more specific how exactly can I limit access to my api based on the requestor allowed scopes ?
I can undersatnd that on the identity server both the api resource and client should be configured and for the client to allow it to request access for specific scopes configured for the api resource, but I'm missing some information about how to validate the scopes.
Are the allowed_scopes part of the access_token ? If so as being part of the access_token, the api resource for which the token was generated should like decript the token and get the scopes or how exactly does this process work ?
Your thinking is on the right lines. APIs receive access tokens and authorize requests in 3 main stages:
First verify the digital signature of the JWT
Second each API endpoint verifies scopes, using the scope array received in the access token
Thirdly more detailed authorization is done using claims
A common way to check scopes is to use attributes on each controller method. Eg in .NET you get some help from the framework and can do this. See also this tutorial for sone other options:
[HttpGet]
[RequiredScope(myscope)]
public IEnumerable<TodoItem> Get()
{
// Do the work and return the result.
// ...
}
Context
We use Identity Server for identity and access control in our solution. Our scope names have the form of URLs so they are 40-60 characters long.
Some time ago we received a request to increase the max length for scopes in the request. The default value is set to 300 in InputLengthRestrictions class and it can be changed very easily. However, after some discussions, it turned out that for now it may be enough to increase the max value to 500 or 1000 but in the future, an even bigger limit may be needed in order to be able to request 10, 20 or more scopes.
Here comes the question. Is it a good practice to request an access token with such a large number of scopes? What are the pros and cons?
My thoughts
From my perspective, the main benefit of having one "super" access token has one main advantage i.e. it is convenient because it allows you to call all APIs.
On the other hand, I see some drawbacks and/or code smells:
The fact that a large number of scopes must be requested may mean
that scopes are too granular.
The fact that a large number of scopes must be requested may also suggest that scopes are used more as permissions. It is especially a problem in the case of long-lived tokens as they cannot be revoked easily.
Requesting a large number of scopes may suggest that you request
more than you actually need. However, it is recommended to "choose the most restrictive scopes possible".
Having a super access tokens expose a higher security risk if such a token is intercepted.
In implicit flow, a token is passed in URL so the large super token can exceed the maximum length of the URL.
Super tokens might be too big to store them in cookies (it is a
different topic if tokens should be stored in cookies).
Super tokens can be quite large so the network performance can be affected.
What do you think? Do you see any other pros/cons of super tokens? I'm not sure but maybe large super tokens can affect Identiy Server performance.
I don't have pros or cons for you, but perhaps this answer can help you.
Looking at IdentityServer you'll see three parts, the resource, the client and the user. IdentityServer has two main responsibilities, authorize the client and authenticate the user. User authorization is actually not the responsibility of IdentityServer. That's why they created PolicyServer.
Consider the following resource:
resource = CalendarApi
scope = Calendar.Read
scope = Calendar.Write
scope = Calendar.Event.Create
The resource is just a logical name. It can consist of one or seperate api's (as in projects), where an api can implement a single or multiple scopes. In the api a scope is an implementation of certain functionality.
Only a client can request a scope, because the client knows how to use the functionality.
Suppose I have two clients: Mvc1 and Mvc2. Mvc1 has a calender view and an admin page, while Mvc2 only shows the calendar.
My configuration:
Mvc1: scope = Calendar.Read Calendar.Write Calendar.Event.Create
Mvc2: scope = Calendar.Read
It has no use for Mvc2 to request all scopes, because it doesn't use the other functionality. It wouldn't make sense to request all scopes. And in case Mvc2 is a third party app, you shouldn't, because they could use it even when this was not the purpose.
Best practice here would be that a client only requests scopes that are allowed (as configured in IdentityServer) and may be implemented by the client.
So far the user was not involved, because there is no relation between scopes and users. However, the client needs the user (as resource owner) to actually access the resource.
It then comes to user authorization to determine whether the user can create events on the calendar. This 'permission' is not the scope.
The scope Calendar.Event.Create doesn't allow the user to create an event. It only allows the client to connect to the resource.
When combining the clients and users, then there is only one situation where a user can create an event: when a user with create permission uses the admin page in Mvc1.
Mvc2 can't access the resource, not even when the user has create permission.
Now getting to your question:
Is it a good practice to request an access token with such a large
number of scopes?
The access token should only contain the scopes that are needed, as described above. Only necessary scopes should be requested by the client.
Agree. The number of scopes should not be too detailed. Don't treat scopes as permissions, e.g. create, edit, read. Though I did as example, a better scope would be Calendar, where the user permissions define what the user is allowed to do (CRUD permissions).
Agree, should be investigated.
I would say yes, as argumented above.
It is still the user that has to be authorized. But you should limit the possibility for clients to use functionality that was not meant for that client.
/ 6. / 7. Hitting limits is a good indication that the architecture may need some redesign. In general you should not expose more than necessary and you should avoid hitting limits.
I suspect the problem is that scopes are used as permissions. Remove the 'CRUD' from the scopes and redesign user authorization. Don't set permissions in claims.
In my design there is no need for a super token, nor will I ever hit a limit. There are only few scopes, the access token only contains the sub claim and policy server tells me what the user is allowed to do.
I hope this helps you in any way. Please let me know if something is not clear.
You can implement Service Account flow for same. Using it you can get token of respective client with all allowed scopes to client.
By this way your token does not have included all scope but has scope allowed to client.
I don't have sample code right now but you can check how service account can be implemented
As a resource server, I'd like to give users more control over their resources.
For example, consider I have a cloud file system supporting OAuth 2.
The user may provide permission to access the files to a client on his behalf.
I'd like the resource server to offer access to specific folder, for example, just photos and not documents.
The names of the folders is a dynamic resource, as it varies among users.
How can I handle dynamic resource authorization? Dynamic scopes?
Also, if the scope is dynamic, how does the client know to request it?
* Couldn't find it in the spec :(
The document rfc6749 which is the OAuth 2.0 spec, defines a way to extend OAuth 2 by using additional parameters(rfc6749#section-8.2).
So, if you want to solve this with OAuth, you could use this approach or something similar:
you define a new parameter for the Authorization Request to specify a resource(EX: folderID=XXXXX)
During the Authorization request, a client can OPTIONALLY specify a resource by using the new parameter
If the parameter is specified, your Authorization Server will generate a "dynamic scope" which must be signed by the Resource Owner
if the parameter is not specified, the Resource Owner can select the resource he wants to share, and the Authorization server can generate the related "dynamic scope" (This scenario implies that the resource server is involved somehow during the Authorization flow)
When the scopes are defined and signed by the Resource owner they are communicated to the Client (it should be able to derive the resource ID from the scope if the latter has been defined by Resource Owner)
When the Client asks for a resource, the resource server also has to make sure that the scope includes the requested resource
Bear in Mind that such approach works better if the amount of resources per user is not very big (otherwise you can be flooded of scopes).
Another method could be to add an extra layer of Authorization behind the OAuth Layer. This additional layer keeps track of the relation client/accessible resources.
Just recently I had to familiarize myself with OAuth/OIDC, and now I am facing the same question - here's what I could think of so far -
You surely have a reason to externalize security (authN, authZ) - that's why you use OAuth. Do you really want your Authorization Server to know about the resources you have in your application?
Scopes - as far as I understood - control access to APIs, not 'resources' in the standard meaning - even though I read about 'resource' typed scopes, but those were again giving access to an API.
If you have resources (files) you want to control access to, you'll probably better off handling it inside your application - and optionally request the list of known clients from the Auth Server, if you have to.
This is the way I am going to try doing it for my own app anyway - it is indeed surprising not to find any resources about this online.
Resurrecting a pretty old question here, but I think the problem is still current.
One useful detail to bear in mind is that the scope requested by the client and the scope allowed by the Resource Owner don't have to be equal. In fact, the scope allowed by the RO doesn't even have to be a subset of the requested scope.
In your case, the scope allowed by the RO can be a set of resource URLs, selected by the RO at grant step depending on the requested scope. Then, by looking at the values in the access token and understanding their meaning, the Resource Server will be able to serve the requested resources dynamically.
I am trying to configure a LinkedIn application for a multi tenant site. I will have 20+ tenants using the same application and the number is going to increase every time.
As per Linkedin API documentation (https://developer.linkedin.com/docs/oauth2) we need to ensure following points
We strongly recommend using HTTPS whenever possible
URLs must be
absolute (e.g. "https://example.com/auth/callback", not
"/auth/callback")
URL arguments are ignored (i.e.
https://example.com/?id=1 is the same as https://example.com/)
URLs
cannot include #'s (i.e.
"https://example.com/auth/callback#linkedin" is invalid)
Can i configure redirect url as https://*.mysite.com/auth/linkedin/callback instead of specifying url of each tenant separately.
You cannot do a subdomain based wild card mapping as the IP should know the RP.
You can change the logic after you get the authorization callback, so you set the cookie and then you will have to redirect the user back to the tenant URL instead of the base URL.
Anyway, after successful authorization, you will be redirecting the user to an action, just figure out the subdomaina and the construct the URL and do the redirection
HTH
EDIT
Since the use of the URL or other approaches seem to be a hack, can you please try to have a facade like application (or Gateway like one) that has a URL that is registered in linkedin and then on receiving the response, it can use a state or other factor to redirect to the tenant URL. This can use a 302 and it will be invisible unless the user is on a very slow network. This approach does not require any hack like approach.
Here state can be a function that takes a tenant info and generates a dynamic hash that is stored for tracking and redirection.
The Dropbox OAuth 2 requires me to set a return URL. Is it possible to implement the OAuth 2 flow with a dynamic return URL?
Background on why I need the return_url to be dynamic: The flow works great if the integration is through a website, however I am working on a product which is managed through a web console, and typically users will access it using the private IP on the unit. This IP is something I cannot know in advance.
Possible Solutions if dynamic return URLs aren't possible:
I host a cloud service of some sort to act as a broker --- the broker is a fixed URL and I relay back the access code to the device.
Use OAuth 1, which doesn't seem to have this restriction.
Florent's comment is correct, this isn't currently possible, as all OAuth 2 redirect URIs are required to be pre-registered as a matter of security. I'll be sure to pass this along as feedback though.
As mentioned though, one thing you may be able to do instead is to use one static redirect URI but encode the necessary information in the 'state' parameter, and decode it as necessary after the redirect back to your app, to handle it as necessary:
https://www.dropbox.com/developers/documentation/http/documentation#oauth2-authorize
Alternatively, you can use OAuth 1, which doesn't require pre-registered redirect URIs. Edit: note that OAuth 1 is only available for API v1, which is now deprecated.