Does OAuth2 support the granting of permissions to another user?
I have seen examples of resource owners granting permission to applications, but haven't found much about resource owners granting permission to other users of those applications.
For example.. Two users: User and Delegate.
User grants permission to Delegate to access some resource (via a web interface, perhaps) belonging to User. Delegate authenticates via OAuth2, and can now see the resource which was protected before User granted permission.
In this scenario, Delegate would have permission to access everything Delegate owns, but also have permission to access some subset of what User owns.
According to RFC 6749 there is no native support for cross-user delegation.
Related
I understand that for an app to access Office365 mailboxes I need a registered app with Application Permissions, e.g. Mail.Read which - according to its description - "allows the app to read mail in all mailboxes without signed-in user".
This is exactly what I need except I don't need and I am not allowed to read all mailboxes within the organisation.
In order to restrict this further I can of course set a ApplicationAccessPolicy which allows to restrict the access to a specific mailbox or generally a PolicyScopeGroupId.
My issue is that when this policy is not active, changed or deleted for whatever reason an app has full access to all of organization's mailboxes which sounds very risky in a bigger enterprise.
Isn't there really any other way to handle that vice versa, so that by default no mailbox can be accessed except a set of defined ones?
The other way around can be,There is a separate Mail.Read permission for both Application and Delegated permissions.
The difference between "App-only vs. delegated permissions"
Permission scopes can be either app-only or delegated. App-only scopes (also known as app roles) grant the app the full set of privileges offered by the scope. App-only scopes are typically used by apps that run as a service without a signed-in user being present.
Delegated permission scopes are for apps that act on behalf of a user. These scopes delegate the privileges of the signed-in user, allowing the app to act as the user. The actual privileges granted to the app will be the least privileged combination (the intersection) of the privileges granted by the scope and those possessed by the signed-in user. For example, if the permission scope grants delegated privileges to write all directory objects, but the signed-in user has privileges only to update their own user profile, the app will only be able to write the signed-in user's profile but no other objects.
"Permissions not requiring administrator's consent" are delegated permissions, while "App-only permissions requiring administrator's consent" are the app-only permissions, which is why it shows up twice.
If you want to access the mail for all the user's in your tenant, then you must have a user account that has that level of access or you need to use an App Only token which grants that scope of access.
I have a multi tenant app registered in Microsoft Active Directory that uses admin consent to gain access to some application scope APIs in the Microsoft Graph API. It uses the /token endpoint to get a token, then calls those Graph APIs. It's working perfectly.
https://learn.microsoft.com/en-us/graph/auth-v2-service#token-request
Now I want to enhance my app to access some delegated (user) scope APIs, that do not allow access at application scope. My app is already configured to request these delegated permissions from the admin at admin consent time. But I'd like to call these APIs as each user in the directory, not the admin who installed my app.
Importantly, it is not feasible for me to have every user in the organization individually go through the OAuth flow for my app.
Is that possible?
Can I impersonate a user somehow by exchanging my application token for a user token?
Can the admin do something programmatically to generate tokens as individual users for my app as if they had been put through an OAuth flow?
No, you cannot convert an Application token to a Delegated token. The only way to act as a specific User is for that User to "delegate" those activities to your application.
Note that Admin Consent only provides consent to your App to operate within a tenant. It is destinct from, not a superset of, User Consent. In order to obtain a Delegated token, you need to receive both User and Admin consent.
Please describe the difference. If user gives access to my app, then Can I use "delegated scenario" to act on behalf of a user and access his/her emails, contacts etc. I am already using MS Graph api to access my users' data but sometimes even after retrieving access token I encounter this message: Resource could not be discovered.
Delegated Scopes are used for scenarios that involve an authenticated user. Unless you're building a daemon/service app or you have a very specific need, it is a safe bet that you should be using Delegated Scopes. Some scopes may still require Admin Consent (i.e. ability to read any users calendar) but the majority only require the User to consent themselves (i.e. ability to read their own calendar).
Application Scopes (aka "App Only") are used for scenarios where there is no user available to authenticate or the application is headless (and therefore no UI in which a user could authentication). These are extremely permissive permissions and always require a Global Administrator to consent to the scopes you've requested. These are also only applicable to Work/School Accounts (AAD) and cannot be used with personal Microsoft Accounts (MSA).
Which scopes are used is a direct result of the OAuth Grant you used to obtain the token.
Authorization Code Grant (authorization_code) == Delegated scopes
Implicit Grant (implicit) == Delegated scopes
Client Credentials Grant (client_credentials) == Application scopes
I'm trying to use the Microsoft Graph API through the OAUTH2 Authentication however I'm struggling to work out how to use Delegated Permissions and not require a user to login.
I'm happy to authenticate the app with myself once, but this will be running on a daemon/service and won't be interacted with via a user. Because of this I can't use the way Microsoft describes Delegated Permissions as that uses /authorize first and then a call can be made to /token.
I know you can use secret keys for /token but it seems that only is using the Application Permissions and not Delegated - which is what I have access to.
Is there a way to authenticate using Delegated Permissions as if I was a user but without a user having to use a sign in page every time?
I needed to do something similar in a daemon app, but application permissions weren't available for the resource to which I needed access (Planner). I was able to accomplish it using the Resource Owner Password Credentials flow and supplying credentials for a service account instead of an actual user.
https://learn.microsoft.com/en-us/azure/active-directory/develop/v2-oauth-ropc
This isn't possible. The term "delegated" is very intentional here in that it means "the user has delegated their permissions to your application so you can operate on behalf of that user". Application permissions are not delegated because there is no user in context to delegate their access rights to you.
Authorization Code = Delegated Permission Scopes
Implicit Grants == Delegated Permission Scopes
Client Credential Grants == Delegated Permission Scopes
Much of the Microsoft Graph functionality works with both Application and Delegated scopes so in many cases you can still execute the same scenarios. There are some caveats such as using the shorthand /me which doesn't exist when there isn't a user authenticated (instead you need to use /users[{id}]). There are however some cases where there isn't an equivalent Application scope and these are regularly looked at in an effort to close the gap.
I understand the OAuth 2.0 spec. allows third-party applications to grant limited access to the application, either on behalf of a resource owner or by allowing the third-party application to obtain access on its own behalf.
I have a scenario, where I have an application and I need the user to get authenticated with some IAM provider. The roles and privileges are configured in the authorization server for each user. I can query the introspection point of the authorization server and based on the scope details, my application can decide the access to any resource for the user.
In this case, the user is not the resource owner. The types of resources the user can access is decided by my application, instead of the user allowing/denying the application to access resources.
Since the user is not the resource owner, can OAuth/OpenId Connect be used in this scenario ? Is it possible with WSO2 IAM?
I tried the playground sample which is available in WSO2. Once the user logs in, there is a window which asks "playground requests access to your profile information" and requesting the user to allow/deny. Can this be avoided, since in my case the user is not allowed to make any decisions ?
If not, what are the other options to authorize/limit access to resources which is decided by the authorization server/resource server, instead of user granting access ?
Thanks,
Albie Morken
In this case, the user is not the resource owner. The types of resources the user can access is decided by my application, instead of the user allowing/denying the application to access resources.
In your scenario, you are relying on tokens issued by authorisation server to access a protected resource. The protected resource is your application. And this application must have internal mechanisms to verify the tokens it receives to grant access.
Short answer to your question is - YES
You can use openID connect for this scenario. And you have two options to adopt,
1. Use access tokens with introspection end point
You can use access tokens to grant access to your application. The client should send the access token as a bearer token as described in RFC6750. When the application end point receives a request, this access token can be validated against introspection endpoint RFC7662
2. Use ID token
ID tokens too can be used as bearer tokens.ID token is a JWT (RFC7519) and is self contained. It contains validation mechanisms as described by OpenID connect spec which are self sufficient to allow grant. And also to you can check claims it contains to authorise the end user. More can be found from this link.
I tried the playground sample which is available in WSO2. Once the user logs in, there is a window which asks "playground requests access to your profile information" and requesting the user to allow/deny. Can this be avoided, since in my case the user is not allowed to make any decisions ?
Consent page can be disabled. According to spec. it can be done by configuring identity.xml as follow,
<SkipUserConsent>true</SkipUserConsent>
It is described in their documentation too.
Hope this helped.
p.s - WSO2IS contains inbuilt XACML engine. XACML is the standard for access control. You can fine more information from this link.