Today we use Azure AD as the OAuth provider with application registrations representing APIs, Web apps etc.
Users are granted access to web apps and/or APIs in order for them to use them.
When using the authorization code flow for web apps…
If the user lacks access to the web app, they will not be presented with an error message stating so.
If the user tries to request an access token for an API they will get an access token with an audience claim for the directory itself and not the API.
APIs or API Management validates incoming API calls by matching the audience claim against the expected and possibly roles/scopes for more granularity when needed.
What I’ve observed so far while evaluating Auth0 is that there’s nothing stopping a user from using a web app without explicit access. Ideally they should be redirected to an error.
Access tokens will contain an audience claim for the API (when requested) despite the user having no explicit access.
I most likely fail in my thinking somewhere but…
Can I restrict access to the web apps by default unless users are provided with explicit access?
Can I ensure issued access tokens doesn’t contain API audience claims unless users are provided with explicit access?
Would you mind sharing the SDK/Quickstarts you were using where you notice this type of behavior? I’m a bit unsure what you mean.
Could you explain what you mean by directory in this context?
Once I understand your setup a bit more and what concerns you’re working through I’ll be happy to assist further. I’d be particularly interested to know what you mean when you say ‘grant access to web apps’ because it sounds like you’re referring to something different than a typical login flow?
For the second question, by directory I mean the Azure AD tenant.
The audience claim in tokens for unauthorized APIs would in that case be: "aud": "00000002-0000-0000-c000-000000000000" and API / API Mgmt would naturally deny that API call as the audience doesn’t match the expected one.
Main question is, can I somehow control web app permissions for users?
The way AAD handles this is that after authentication, you’ll be presented with a (if you lack access): AADSTS50105: The signed in user 'john.doe@mydomain.com' is not assigned to a role for the application '6f1fddff-e43b-4718-80e5-5b64a2bad8a3'(My Web App).
It’s a SPA without anything secret but it’s to communicate back to the user whether they should be able to use the app at all.