Would it be possible for a background service to use identity of specific shared mail box user in conjunction with the delegated access permissions without actually requiring an end user to authenticate ?
How would this be achieved in office365 exchange services with OAUTH 2.0 ?
Regards
Would it be possible for a background service to use identity of specific shared mail box user in conjunction with the delegated access permissions without actually requiring an end user to authenticate ?
If you use the client credentials flow https://learn.microsoft.com/en-us/azure/active-directory/develop/v2-oauth2-client-creds-grant-flow so you service is then getting an Access token using a SSL certificate of client secret. It can then impersonate (so it not delegate access) any Mailbox in your tenant and send as that user.
If your on Office365 then you may want to look at the Graph API instead that allows you to have a much tighter set of permissions (eg you could for instance just grant your app/service SendAs rights) when compared to EWS which only allows full Mailbox access.
Related
Our OAuth client application is built with Spring (through JHipster). The OAuth provider only serves the authentication functionality, but not the authorization functionality. Ideally, we should only allow a small group of people to access our OAuth client application, but not all those users who can sign in to the OAuth provider.
A solution I can think of at this moment is to create a custom user role to control the access in the OAuth client application. That, however, only can be done after the user's first sign-in when the user account data is created in the application.
Any better solutions?
Ideally you would apply user access control before creating user account data is created in the application. You could do so by providing an application specific scope or claim in the token that is generated for your application (aka. Client). Upon receiving the token, the application would check for the required attribute in the token before allowing access.
In our application we use EWS and basic authentication.
An user can get access to own mailbox only or to all mailboxes in his organization if he has admin credentials. Now we are trying to replace basic authentication with OAuth2 authentication.
We registered the application on Azure portal, added the permission "EWS.AccessAsUser.All".
For an admin account everything works well. Our application can get access to any mailbox in admin's organization.
The problem is in that we cannot get an authorization code for a standard user account.
"TestApp needs permission to access resources in your organization that only an admin can grant" is shown.
So the question is: is there a way to get access to user's mailbox using EWS, OAuth2 and user's credentials?
With oAuth you need to grant consent for your application in a Tenant eg
https://learn.microsoft.com/en-us/azure/active-directory/manage-apps/grant-admin-consent once you have granted tenant wide consent any user should be able to use the application unless you apply restrictions. If your application is being used by other companies then you need to have a Multi Tenant application registration and the client will need to consent to its use in their tenant before they can use it.
Can I define custom scope(s) and have them returned when using the client credential flow in Azure AD?
In my experiment, I configured 2 Azure AD applications, one for a Web API and one for a client (Web API Client A). I added a scope to the Web API but when requesting the access token via the client credential flow, the scope wasn’t returned. 🤔
Also, it only allowed me to request an access token when using .default for a scope, i.e. api://web-api-client-credential-flow/.default.
I ran across this Azure Feedback item: V2.0 Client Credentials Implement Scopes so it appears scopes aren't supported in Azure AD under the client credential flow?
What’s the point in giving my Web API Client A application permissions for that scope if they are not returned? How could the Web API know if the daemon application has that scope to perform the necessary action?
It would seem I would have to use application permissions?
Yes, you have to use application permissions.
Scopes aka delegated permissions only apply when a user is involved in the login process.
They allow you to act on behalf of a user.
Application permissions are sort of roles given to the application itself.
They only apply when doing client credentials authentication, where no user is involved.
You can define application permissions on the app via the Manifest in the app registration.
These can then be assigned to the client application.
When getting the token, you must use .default because you cannot change your app permissions dynamically.
You always get what has been granted already.
In the token the permissions will be in a roles claim.
Can I define custom scope(s) and have them returned when using the client credential flow in Azure AD?
No, but you can define application permission(s) via the manifest (definitely not as nice as the UI for delegated scopes) and have them returned via the client credential flow:
Then you can provide the client app permission:
Now when requesting a token with a scope of api://web-api-client-credential-flow/.default the "scopes" are returned in the roles claim. Sample JWT
Yes, you need to use api://web-api-client-credential-flow/.default for client credential flow.
And the application permissions will be returned in roles instead of scopes.
I am trying come up with a bash script to register an application in Azure AD using the /beta/applications endpoint from Microsoft Graph.
To call /applications, I would need to get an access token.
Is it possible to get an access token for Microsoft Graph using just email address/password (Without a client-id)? I am looking for something like "Resource Owner Password Credentials Grant Flow" mentioned in OAUTH2 spec.
Any other alternative I can look into. I want to write a simple script that would manage application registration and any updates to the application in future.
Yes, there are several means of running a script against the Microsoft Graph API without a user present:
AD supports the resource owner credential grant that you described in your question. This flow doesn't support some new auth features like multifactor auth and you'll have to be very careful about securely storing your credentials.
The other option is to use V2 auth client credential flow. In this case, the tenant admin consents to the application on behalf of the tenant. Afterwards, the application can run without a user present. One benefit of this flow as opposed to the V1 resource owner credential grant is that you pass a client credential which can be revoked and re-generated if needed (rather than dealing with raw user credentials).
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.