Securing shared APIs with Azure AD

0
votes

I'm working with a client to define a security strategy and have got stuck trying to get something working. I'm new to Azure AD so this may actually not be possible.

Consider the following application landscape. I have 4 "API" applications:

  • API-A, requires interactive user and role based permissions
  • API-B, access via service demon, client_credential grant
  • API-C, must not be authenticated against directly
  • API-D, access via service demon, client_credential grant

A user / demon authenticated against API-A or API-B should be able to access API-C as well. However the demon authenticated against API-D must not be able to access API-C.

I was expecting to be able to use the "Expose an API" and "API Permissions" of the App Registrations to be able to control to "roles" returned in the JWT, I cannot seem to get it to work or find any decent guide on how this can be achieved.

EDIT: For clarity the API applications are not hosted within Azure, I am just looking to use Azure AD to provide authentication

1
azureazure-active-directory
I've written about these things here: joonasw.net/view/azure-ad-authentication-aspnet-core-api-part-2 and here: joonasw.net/view/defining-permissions-and-roles-in-aad. You are looking for "application permissions" I guess? – juunas

1 Answers

0
votes

It may be helpful for you to distinguish between client apps and API apps (or resource servers in OAuth2 lingo). Each of them has to be registered separately. Your list above seems to merge them together, which is a likely source of confusion for you.

The former (client apps) acquire tokens, the latter receive them from the clients with the service request. Authentication is only only involved when client apps acquire tokens. APIs do not authenticate - they use tokens to authorize access to their services. Clients acquire tokens either on behalf of a user - and the user authenticates and consents as part of the process, or on their own behalf (client creds). In AAD an API app may expose/define scopes/permissions which may be included in one or both of these token types. An API may decide not to require any tokens (sounds like your API-C). You Expose (available) Permissions on API apps, you specify (required) API Permissions on client apps. At runtime (if using the AAD V2 endpoint) a client may request fewer scopes than it is is configured with as Required. That applies only if the client is using delegated tokens (user based). (Note that an API app may also be a client app to another API app (common in multi-tier systems).

BTW, where the clients or APIs are deployed is totally immaterial to the above. At most deployment affects the value of the reply url you need to specify for some client apps (not APIs).