@Albin_Issac I see, the authentication handler is actually adding the newly created oauth users as members of the everyone group.  I thought it was going to use anonymous for some reason...  but everyone is better than using the admin group which I thought it was   The last question I have is regard...

Yes, the bearer token (or assertion) does contain the sub, like your example.  But in the generated access token, in your example and in my code, the sub is converted to admin. So, for the actual content request when the access token is validated how does the scoped permissions get bound to the requ...

Regardless of including the "sub" attribute in the JWT Bearer token, the generated access token always changes the sub to admin.  Since I am following the server-server pattern, I am using the urn:ietf:params:oauth:grant-type:jwt-bearer grant type.   In the example you referenced, if you decode the ...

@Albin_Issac I have this working for the most part now - In my flow I am using the server-server integration, and I am curious about the user and user permissions.   In my working code, and in your example, when I decode the access_token returned from the Adobe Granite server the subject is always s...

Thank you  @Albin_Issac 

@Albin_Issac Turns out I was overthinking the solution,  but to be fair there is so little documentation on this pattern.  Using the ScopeWithPrivileges does work as expected...  with one issue.  AEM returns a 404 when the token is not valid.  Can this be modified to return a 404 is the resource is ...

Thanks.  I have read this.  But, I'll have a read though it again... this time in more detail.Thanks again

I am looking for documentation on the correct approach/pattern for JWT OAuth validation when using the Registered OAuth Clients in AEM. I have searched the internet and I have not found any good examples of how to validate the JWT OAuth Registered Client token.  I understand the flow from a 3rd Part...