From the documentation it seems that using an application that is in the B2C tenant and thus hosts user accounts that there is no way to directly access Microsoft Graph API via a logged in user per their own context.
I want to establish the use case properly so that the solution is that which makes the most sense.
The use case is that if a user wants to edit claims for example such as permissions they would be able to do so while logged in through Azure B2C.
The flow would be. Logged in user -> can change certain claims information such as address, surname, and other custom policy fields (SEO contact permissions.)
Is the proper way to do this is to build a proxy that will take the application's AD application permissions which are allowed to call out to Microsoft Graph and pass along user context so that the scope will be limited to that user only?
For example. User logs into the app.
- The app has AD permissions that are granted admin consent
- Create a client secret to prove application identity upon request of a token
- Now can access Microsoft Graph api Ref of Registering an app with Microsoft Graph api
What's not clear here exactly is the next part. My user is logged in with Azure B2C. Should I just pass along their id token which has their claims to the application? How do I put in scope/context of the logged in user of the app permissioned access to Microsoft Graph?
This part is not clear in any documentation.
- I don't want a logged in user to have access to everything.
- Is a proxy the only way to do this?
- If a proxy is the only way to do this what identifier or id is what should be used to pass along to the query to assure only that user is in context?
- Am I thinking of this incorrectly and or is there a better way to do this other than a proxy?
The documentation says this.
Apps that have a signed-in user but also call Microsoft Graph with their own identity. For example, to use functionality that requires more elevated privileges than the user has.
That doesn't fit exactly into my use case above or address it really but I think it is related. The functionality should be considered to be an elevated permission but to the scope of the user. This user can change this claim via their own logged in entity. What do you call that and what is the best way to solution this?
Lastly, is there anything that should be known in the MSAL library including Angular and React that would be useful in this process? It seems like I will have to converge the 2 to obtain the access token of the app and of the person and proxy those out to a backend service (the proxy) to then do a body of work.
Am I thinking of this correctly?
This Stack is the closest to relevance but doesn't ask or solution the entire use case as I have here. But is useful for illustrating the confusion.
