May be I am missing something here but what the point of client requesting scope?
What I mean is that when a client request a token he/she can say "I want everything" i.e. read/write/delete/update etc.
In reality, user might only have read access. So what's the point of requesting these in scopes? or its not a good practice/idea to put these in scope? If not then what do you really use it for?
I have seen in some places where it's used for Email, Username while others its used for repo:read, repo:write...
Isn't Authorization server going decide what permission the user has?
Thanks
I'm not sure if I understand your question fully but here goes. In a typical OAuth scenario, there's the:
OAuth provider - has the protected resource, issues access tokens to resource (e.g. Google)
End user - owner of resource (e.g, Google user)
Relay party - uses OAuth to access protected resource from provider on behalf of end user (e.g, some random app that does something with your google profile)
When you use the relay party's application, it needs to get your information from the OAuth provider. Most providers have different levels or "scopes" of access to the end user's information - it's usually not an all or nothing access. The relay party must define the scope of access, and ask the OAuth provider, the provider presents the scope of access request to the end user, and finally the end user can decide whether to grant the relay party that scope of access or deny it.
So without scope, how can a relay party request a granular level of access?
Related
We have built a React web application that authenticates users with Microsoft via OAuth ( #azure/msal-browser package). Users are redirected to Microsoft auth page during signin, and then redirected back to our site once authentication has completed successfully. This is all working as expected.
However, we are in a position where we wish to add a custom PIN mechanism to protect some of our workflows. PINs will be encrypted/salted and stored in our own API, along with the existing mapping between Microsoft/Azure users and our own user state/records. In order for users to change/reset their PIN, we want to force them to reauthenticate with Microsoft before changing their PIN. I have not dealt with OAuth2 in a while, and am not entirely certain how this might be possible (since current auth workflow does not involve our server at all).
Ideally, users would navigate to the "Reset PIN" page and initiate the workflow. If possible, authentication would be handled through a pop-up (so as to not lose page state), which I think is possible as per documentation? If this is not possible, even a redirect to the same page with a specific query parameter (to indicate post-authentication) could work. The user would then be able to change/confirm their new PIN. At this point, a request would be sent to our API, including both the PIN and something from Microsoft that would allow our server to validate that the user did indeed just re-authenticate (proving they can change the PIN).
The primary sticking point is that our API must be able to verify that the user has just re-authenticated with Microsoft! One way to think about it would be that if a user gained temporary access to an unlocked authenticated workstation, they should not be able to perform restricted actions (as they do not know the PIN), nor be able to change the PIN (as they do not know the user's credentials). Yes, yes, I know physical access is effectively a compromise to any security, but this is a higher-level requirement...
I am guessing this workflow is possible, but am not certain how it might be possible. Would we use a different authentication workflow for this particular use case? Any pointers on a workflow we could investigate or use for this?
I can give you some info about how this should work. This type of flow can require a high level of extensibility in the authorization server though.
CLIENT REDIRECT
The client can send the OpenID Connect acr_values parameter, indicating the assurance levels it requires. In your case you would send two values.
CUSTOM AUTHENTICATION FACTOR
The user will perform standard authentication first, eg passwords. Then you would implement a custom second factor that uses the user identity and some custom logic to call your custom API.
ACCESS TOKENS
After authentication has completed, the authorization server will issue access tokens to the client. High privilege claims should only be included when strong authentication has been used. Some kind of scripting would be used here, that can read authentication result attributes.
API AUTHORIZATION
APIs should receive short lived access tokens. If it contains the high privilege claim, you know that your PIN requirements have been met.
CAN YOU SIMPLIFY?
It feels suspect to do your own PIN management. Can you outsource this, eg use a second factor of time based one time password (TOTP) instead? Mobile platforms such as the Google authenticator app provide tested solutions.
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.
Currently, I'm trying to access Graph API from within a (Standard) Logic App to search for Sharepoint documents. To do so, I try using the following flow (I need delegated permissions, application permissions cannot use search endpoint):
https://techcommunity.microsoft.com/t5/integrations-on-azure-blog/calling-graph-api-from-azure-logic-apps-using-delegated/ba-p/1997666
As one can see in the blog post above, there is a step where the following string gets passed into the body of the first request to get an access token for a delegated user:
grant_type=password&resource=https://graph.microsoft.com&client_id=client_id&username=serviceaccountusername&password=serviceaccountpassword&client_secret=clientsecret
Now the client secret and service account password are two things which I absolutely don't want to have visible in the Logic App code and/or designer screen. Is there a way to securely read these from for instance the 'app settings' (in which I could reference them from a KeyVault)? I really can't find a good way on how to achieve this and I think it's a must to not be able to read these secrets/passwords from the Designer/code view.
Definitely use a KeyVault and make sure that for all steps involved, secure the inputs/outputs where ever that secret information may be visible.
The below example is the call to get the secret and therefore, I only want the outputs to be secured.
Result
With your HTTP call, it's likely that you'll only want the inputs to be secured.
Be sure to use a managed identity on your LogicApp and then assign that managed identity to the KeyVault Secrets User role on the KV itself.
There's plenty of documentation on this topic ...
https://learn.microsoft.com/en-us/azure/logic-apps/create-managed-service-identity?tabs=consumption
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 hope the following question makes sense:
I manage my users in ActiveDirectory.
I authenticate them via IdentityServer3.
I authorize the APIs via the AD groups that the user is in (acting as security roles).
How should I set up IdentityServer3:
Must I use my own custom UserService to access ActiveDirectory?
and does that replace the MembershipReboot / AspNetIdentity support (or am I misunderstanding what the UserService is)?
Or should I use one of the MembershipReboot / AspNetIdentity packages from IdentityServer3, and somehow customize them to map to ActiveDirectory (and if so, how)?
Seems there is no "mapping" and should not be a mapping from AD to a membership-reboot or an aspidentity or the newer identity-reboot user stores. The reason seems to be simple: mr and aspid or ir are all ways to store the user information in a persistent way (some sort of database or repository), which is already done in AD.
The userservice is enough. It causes the ASP Identity objects to be populated, and the middleware to work as expected, calling user authentication, and user or resource authorization correctly and automatically, after the client calls are "decorated" with "Authorize" attributes or after returning from the OP (the OpenID-Connect Provider) or from separate authorization or resource providers, in security calls.
Answer update: Now in IdentityServer4 the UserService has been deprecated and instead you use IResourceOwnerPasswordValidator.
See here for working code and a detailed explanation, in the answer after the accepted one (vote it up please)
IdentityServer4 register UserService and get users from database in asp.net core