I'm running into an issue attempting to use the provisioning api groups scope in a readonly mode.
I've authorized my service account in a google apps domain with the following scope
https://apps-apis.google.com/a/feeds/group/#readonly
Which according to this document is the correct scope.
Requesting an auth token with a scope of either:
`https://apps-apis.google.com/a/feeds/group/#readonly`, or `https://apps-apis.google.com/a/feeds/group/`
results in an invalid_scope error.
If we look at the actual provisioning docs at https://developers.google.com/google-apps/provisioning/auth the scope is listed as https://apps-apis.google.com/a/feeds/groups/.
Using the readonly version of this scope (https://apps-apis.google.com/a/feeds/groups/#readonly) in the google apps admin panel results in the results in the following errors:
requesting an auth token for https://apps-apis.google.com/a/feeds/groups/#readonly, raises an invalid_scope error.
requesting an auth token for https://apps-apis.google.com/a/feeds/groups/, raises an access_denied. I believe this would be expected behaviour as we did not authorize a read/write version of the scope.
We have tried all different combinations of the scopes, but have had no luck. The only way that everything works as expected is if we both authorize, and request an access token with the https://apps-apis.google.com/a/feeds/groups/ scope. In our use case, we cannot allow read/write privileges on this API.
Other examples of inconsistency in the docs:
The English version (http://support.google.com/a/bin/answer.py?hl=en&answer=162105) lists the scope as https://apps-apis.google.com/a/feeds/group/#readonly
The Spanish version (http://support.google.com/a/bin/answer.py?hl=es&answer=162105) lists the scope as https://apps-apis.google.com/a/feeds/groups/#readonly
What is the official supported read-only scope for the groups provisioning api?
The read-only scope only works with Marketplace apps and 2-legged OAuth.
You could create a delegated admin who only has read, not create, update or delete rights to groups. Then use the read/write scope. The scope won't block write operations but the users delegated rights will.
Related
I want a backend app to use another backend service's API, and control per app what it is authorized to call on the backend service. I am using OAuth 2.0 client credentials flow and Keycloak as the authorization server.
I expect roles defined for the backend service and set for the backend app to appear in the access token I request from Keycloak. But the only thing I can manage to appear, are realm level client scopes.
I tried the following (I don't expect to need all of this, but I wanted to try anything that made a little sense):
created realm Test
added client scope on the realm (realm-clientscope1)
added roles on the realm (realm-role1, realm-role2)
define client "backend-service", made this a "bearer-only" client since it doesn't have to authorize itself to other services
create roles on this client (backendservice-role1, backendservice-role2, backendservice-role3-comp)
define client "backend-app", made this a confidential client, with service account enabled
added role on this client (backendapp-role1)
assigned realm-clientscope1 as a default scope
on the scope tab (backend-app Scope Mappings), turned off "Full Scope Allowed", assigned realm-role1, realm-role2, and client roles backendservice-role1, backendservice-role2, backendservice-role3-comp
assigned service account roles with the same roles as on the scope tab (realm-role1, realm-role2, and client roles backendservice-role1, backendservice-role2, backendservice-role3-comp)
After all this, I used Postman to get an access token for grant_type client-credentials. The only thing on the access token is the realm scope "realm-clientscope1".
Why all these options to set service account roles, etc. If they don't show up?
I assume I am misunderstanding how roles are used, but I can't find a proper explanation either.
To try and cover all bases, I also turned on Authorization Enabled on the "backend-app" client, and under authorization, tried to define authorization scopes, policies and permissions that made some sense.
This too, did not result in any more authorization info appearing on the access token.
The last thing I tried, is changing my "backend-service" app from "bearer-only" to "confidential" with Service Accounts Enabled. This also did not make a difference (as expected).
Keycloak version is 15.1.0 (thanks for asking, dreamcrash).
A little late, but I hope that it can be helpful to someone having the same problem.
Basically, it's necessary go to Client scopes tab, and add roles to default scope.
Notice that desired role must be setted in both Scope and Service account roles tabs or it can be setted Allow full scope in Scope tab, and then just set the desired role in Service account roles tab.
EDIT: I forgot to say these configurations must be set in client.
So, in my JWT token, I can see the role:
I am building an app which authenticates via microsoft and needs various that predominantly uses Delegated permissions. I use the v2 auth endpoints to do incremental authentication, only asking for additional scopes when the user needs them.
This has worked well for the many delegated permissions I have so far. In many cases I need admin approval for these permissions, but I have a flow for that which works well.
One of the scopes I have used as a delegated permission is "User.Read.All", I now need the same scope on the application permission level. But I am struggling to work out if there is a way to do incremental authentication for application permissions. The docs say to use the generic endpoint where you don't specify scopes, but this then asks for all the scopes I have on my application registration rather than just passing in the scopes as a param.
It has nothing do with the endpoint and the scopes you specified. Since you use Delegated permissions in your original job, so I consider you use auth code flow or username/passord flow. If we use auth code flow or username/password flow, we can't get application permission when we do authentication although you have assign the application permissions to your registered app. If you want to get application permission when do authentication, you need to use client credential flow instead.
It is not possible to do this unfortunately the consent flow allows either a dynamic set of delegated scopes to be submitted or /.default which acts like the v1 endpoints and requests all scopes for that client. See these docs
Could anyone explain how a MSFT Oauth2 client scope with a URI of https://outlook.office.com (needed for SMTP AUTH or IMAP, for example) can be specified in a corresponding AAD permission when outlook.office.com is not listed in the resource API list ?
MSFT push Graph (which does have e.g. an SMTP AUTH permission), but they have confirmed that SMTP AUTH and IMAP are implemented only in the outlook resource API. Testing confirms this: if the client uses a scope of https://graph.microsoft.com/SMTP.Send and an AAD Microsoft Graph permission of SMTP.Send, authentication fails. The acid test lies is the ‘aud’ claim in the Access token: if it is “00000003-0000-0000-c000-000000000000” (aka Graph) authentication fails whereas an ‘aud’ of https://outlook.office.com will succeed (other things being equal).
I would have thought naively that the client scopes and AAD permissions resource API should have the same URI.
I can’t see how granular permissions – where the AAD permissions are a superset of the client’s scopes and clients ask for the minimum they need at the time they need it – can work if I cannot specify the superset in AAD!
I have asked MSFT for enlightenment but no response.
=====
Additional tests:
If AAD Graph permissions are null and the client scope is just https://outlook.office.com/SMTP.Send, the access token has an ‘aud’ of https://outlook.office.com and an ‘scp’ of SMTP.Send, and authentication is OK.
But if the client scope also contains a Graph scope such as Mail.Send, ‘aud’ changes to 00000003-0000-0000-c000-000000000000 (aka Graph) and subsequent authentication fails with ‘incorrect credentials’. I would have expected a “scope asking for one token for two different resources” type error message from the token endpoint.
And, as would be expected, if the client scope is just SMTP.Send (or https://graph.microsoft.com/SMTP.Send; the Graph URI prefix being now the default) authentication fails with ‘incorrect credentials’
These are using the V2 authorisation and token endpoints – as recommended by MSFT.
====
Further comments in response:
#Allen Wu - I cannot find IMAP.AccessAsUser.All, POP.AccessAsUser.All and SMTP.Send listed under Exchange (API permissions => + Add a permission => Request API permissions /Microsoft APIs => Exchange or under Office 365 Exchange Online (API permissions => + Add a permission => Request API permissions / APIs my organization uses => Office 365 Exchange Online) . They are only listed under Graph. This leads to the weird situations that:
if a client uses (e.g.) SMTP.Send (or https://graph.microsoft.com/SMTP.Send) scope, authentication fails even though MSFT instruct (vide your last link) that the corresponding permission must be registered in Graph
if a client uses (e.g.) https://outlook.office.com/SMTP.Send scope (as instructed by MSFT), the client cannot add further https://outlook.office.com permissions (because the resource API is not listed) or use additional Graph scopes (because authentication fails and it would appear to be asking for one token to cover two APIs anyway)
Vide your comment “We see that the permissions are under Microsoft Graph in the Azure portal, but in fact the same has been added to the outlook endpoint”, MSFT could pre-empt much confusion (other StackOverflow posters have logged similar problems) if they simply listed the outlook.office.com API in AAD API permissions until Graph accessed a complete set of endpoints as well as permissions. I realise they want developers to use Graph, but the present situation is akin to being half-pregnant!
In this case, you just need to select the Microsoft graph permissions (SMTP AUTH or IMAP).
Currently when you need to get an access token, you can specify the scope as https://outlook.office.com/{SMTP AUTH or IMAP permission}.
I think the permissions are still in change. The Outlook permissions should be included in Microsoft Graph in the future.
When requesting scopes for both channels:read and identity.basic I get the following error:
Invalid permissions requested
Cannot request both identity scopes and other scopes at the same time
What's the solution for this? I'm interested in identifying if a user is an administrator and listing his channels. I'm requesting the identity.basic scope above as it's a prerequisite for the users:read scope. Do I really need to get the user to click "Authorize" twice for such a thing?
No. You do not to authorize twice. If you need additional scopes - because you want to access the API methods - you need to use the Add to Slack OAuth flow instead. That one will give you access to all scopes.
The Sign-in-with Slack OAuth flow is meant for quick user authentications only and does therefore not include any scopes that would require the user to confirm them (like users.read). So you can only user identity.* scopes for this flow as clearly stated in the documentation under Valid parameters / scope.
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.