I am using IdentityServer4 to authorize a device using Device Flow. When the device is authorized I need to add a claim that is returned with the Device's token. The data for that claim is acquired during the consent. The claim is not associated with the user that performed the authorization grants, it is associated with the UserCode from the device.
It appears that the DeviceCode table used in EF Storage has a data column that would help store that claim. However the JSON data is fixed to only include IdentityServer4.Models.DeviceCode. Even if I extend that POCO to include the extra data point I still need to get the data into the identity_token's claims.
Am I heading down the wrong path? I would wind up with implementations of IDeviceFlowCodeService and IDeviceFlowInteractionService and IDeviceFlowStore. Dont I also need the token\connect override as well to add the claim?
Device Flow Interaction Service
rfc8628
Related
We are looking at integrating our apps with Openid connect for our react based apps. We have ui and relevant permissions based on user - menus, navigations etc.
Can anyone point to spec or suggest on how do we handle such permissions in relation to openid connect or oauth. Basically how do we make this permissions available to ui, one approach is dedicated API for ui permissions again authorized by access token.
Another approach is permissions in token itself. Scope is one way of holding info, but it is for delegated access. Hence we are thinking to use multivalued custom attributes for holding roles and permissions in access token. But these permissions can also be huge sometimes and thinking hence if it is good idea to keep permissions in access token.
Any valuable pointers or any design approaches for handling ui permissions list please let know, we highly appreciate it.
The most flexible option is a custom API endpoint. An access token should hold important identity values such as these:
User ID
Roles
Company ID
Tenant ID
Country Code
Subscription level
These are claims, and are populated at runtime for each user, unlike scopes, which are fixed at design time.
Access tokens are designed only to be used by APIs, and clients should never read their payload. A good practice can be to return opaque unreadable access tokens to clients, to enforce this.
The actual permissions for a role can be looked up by the API once, then cached. This is preferable to storing large payloads in access tokens.
Finally, permissions for UIs may originate from two data sources: the identity data and your business data. The API can combine a result from both data sources, and transform the result to what the UI needs. Eg which columns are visible, which are read only and so on.
I don't really understand the protecting API using APIResource and APIScopes
I have an angular client application which is calling a .Net APIs lets say API1, Api2 , How can I define the values in APIResource.
I am going through the Identity server4 (version 4.0.0) database table after migration. I found the tables as below
ApiResources
ApiResourceScopes
ApiResourceClaims
ApiResourceProperties
ApiResourceSecrets
ApiScopes
ApiScopeClaims
ApiScopeProperties
My understanding was either we can use 1-5 tables for API setups or we can use 6-8 tables. I tried with tables 1-5. Added values in ApiResources ,ApiResourceScopes & ApiResourceClaims but getting below error
[18:03:53 Debug] IdentityServer4.EntityFramework.Stores.ResourceStore
Found ["TestAPI.Read"] scopes in database
Values in Tables
what is the use of ApiResourceClaims table? is this returning user claims with access token?
How do I access this scope from the client?
Is there any other tables, do I need to add data?
First I recommend that you read my answer here
what is the use of ApiResourceClaims table? is this returning user claims with access token?
It contains a list of user claims that will be included in the access token. Meaning, the names of the claims that it will then take from the user database.
How do I access this scope from the client?
You need to tie an ApiScope. You ask for a ApiScope that then will include one or more ApiResources.
ApiResources represents the individual API's in your system. So, you have one ApiResource per API. You use the ApiResource name and secret to let individual API authenticate against IdentityServer and login to for example get details about the access token (Token introspection)
I think this picture I have below shows the relations between the various parts:
The client asks for a ApiSCope and that will then create an access token that will give access to one or multiple ApiResources. Each ApiResource might using the userclaims ask for additional user information that you want to have present in the Access token. Perhaps for the authorization step in the API. To determine if the user is really allowed in or not.
To complement this answer, I write a blog post that goes into more detail about this topic:
IdentityServer – IdentityResource vs. ApiResource vs. ApiScope
I want to have an architecture made up of these devices / programs with different roles (which are all separated, none of these roles must exist in one and the same instance):
CLIENT
AUTHENTICATION-SERVER
AUTHORIZATION-SERVER (there can be a multitude of these)
RESOURCE-SERVER (also many possible)
And:
I don't want to use any websites a user has to navigate to.
From my studies of OAuth and Open ID Connect I would assume that a Client could get an ID_TOKEN (after authorization) from an AUTHENTICATION-SERVER and could then request ACCESS_TOKENS to different resources from the AUTHORIZATION-SERVERs.
I guess the method I described allows identity theft on the client side.
I cant find a way to easily get id tokens from an authorization server to a client (which I could then use to authenticate to multiple authorization servers). My clients are trusted. I want to use native apps and implement open id connect among them anyway.
I do not want to use any websites as of now and still need to be able to have a secure communication with associations of claims to users and everything. Are OpenID Connect and its possible 'Flows' appropiate for this? Are there any other implementations that would allow the flow I described (or mabye derivations of OpenID Connect)?
It's not recommended but if you really don't want to use a browser (which is somewhat anti-OAuth/OIDC and is full of limitations) then ResourceOwnerPassword grant type is the one you'll need to use. This will not return an id_token though, just an access_token.
id_tokens exist to support front-channel browser-based sign in flows, they serve no purpose if using the ROP grant type.
Access tokens are issued by the authentication/secure token service (IDS4 in this case) and grant the client (optionally with user consent) access to the resource. The resource then has its own authorization rules to enforce scope and user-related ACL/business rule access controls.
I am looking to implement SSO in all my future php/angular applications. I see there are services (Auth0, oauth.io, etc) that are sort of the middle man of an SSO app and there are protocols such as OAuth 1.0/2.0 but in regards to creating a custom SSO solution (using aforementioned OAuth protocols, I assume), I am a little foggy on the complete flow of the process.
What I do get:
App gets Access Token
(optional) App validates Access Token
App (with Access Token) gets access to a particular API and returns result. For
example, Facebook profile information.
What I don't get:
What to do with that information once I have it. Do I retain the access token and request information from the API source each time they login? How do I relate my own application data to the API data? Would I create a different kind of user record that just contains the access token and application's userid?
Do I retain the access token and request information from the API source each time they login?
If the token does not expire, you can hold on to it in a data store and use it with each request. Many times, though, the token will expire, and you need to request a new one each time you start a session. In this case you'd probably store the token in memory instead of a permanent storage location.
How do I relate my own application data to the API data?
I think we'd need to know a little more about your application to answer this question.
Would I create a different kind of user record that just contains the access token and application's userid?
Again, we'd probably need a little more information about your application. If you were persisting the token (in the case that it doesn't expire), then you need to make some considerations about how you want to store it. If not, you can probably just put it into a local variable or session.
I am trying to make my web service identify specific client data to return as JSON. I am not sure this is the right way, and I'd love some advice.
The way it currently works is:
Database table for users with an appropriate company_id where they belong.
Upon logging in, an authentication service issues JWT tokens with the company_id in the token payload.
The clients sends HTTP requests with the token, after which a service verifies the validity of the token, and then the specific route returns data with SQL doing a WHERE company_id = company_id_in_token.
The red flags I'm running into are:
Having user data in the token payload. SSL will negate this, but I am worried about bad design.
Having to include a company_id column in every single table for the filtering.
Please, I kindly ask you to rip me a new one.
If you refer to the OpenID specification, it states that you send the id_token, but signs it for later verification. Also, if the upn or sub claim is available, you can infer the tenant from this data. However, in case if the userin question works on behalf of another tenant, special headers are required to infer the tenant, example contextual tenant can be a header that contains the tenant under context.
In case of having tenant id column, it is a good practice to have a tenant id column in the core business objects tables. There will be no tenant id column in a table that is dependent on the core business object, because it by itself doesn't convey any significance.
HTH