Feedback on making use of this library in a project about ra-auth-msal HOT 5 CLOSED

Just to add a summary of what I understand (please correct me if I am wrong).

In summary, if I was to use Microsoft Graph to find out what permissions the user should have, I would use the access token, else I would use the ID token. Possibly it is more secure to receive both tokens (ID Token for authentication and Access Token for Authorization) but I am not clear on that point.

A user shouldn't be able to get hold of an access token if they weren't also able to get an ID token. I think it is the responsibility of Azure to only produce an access token to someone with the matching ID.

So in the case your API is using Microsoft Graph to validate the access token, then it should be appropriate to send the access token to the API.

But if your API only wants to use Azure AD for Authentication and not Authorization, then it is appropriate to receive the ID token (also maybe validate the issuer and the audience). Once the API has securely validated who you are, it can use it's own database/logic to calculate which permissions you are entitled to (no need to call Microsoft Graph).

ID tokens are decoded using asymmetric cryptography, where public keys can be downloaded and rotated using the issuer URL provided (the one with your tenant ID in it), while access tokens are passed as they are to Microsoft graph (no need to decode).

For example, in postgREST you can just set the secret to the public key and it does the decoding for you. You might (not sure it is 100% necessary, but I do it anyway) want to validate issuer and audience in the pre-db-request. Other APIs will similarly need to create a function that decodes the ID token (received as JWT)

from ra-auth-msal.

Oh nooo. I had the .env in the wrong directory. It was in src/ and needed to be placed one level up, ../

from ra-auth-msal.

I found that I needed to implement my own http client for my dataprovider (postgREST):

export const postgrestHttpClient = ({ msalInstance, tokenRequest }: MsalHttpClientParams) => async (url: string, options: Options = {}) => {
  const account = msalInstance.getActiveAccount();
  const authResult = await msalInstance.acquireTokenSilent({
    account: account as AccountInfo | undefined,
    ...tokenRequest,
    scopes: tokenRequest!.scopes !== undefined ? tokenRequest!.scopes : [],
  });
  const token = authResult?.idToken;
  const user = { authenticated: !!token, token: `Bearer ${token}` };
  return fetchUtils.fetchJson(url, { ...options, user });
};

The main reason is because the implementation in the docs sends the access token instead of the idToken to the API. Maybe in some cases that is preferred, I am not sure. But in my case this is what I needed.

from ra-auth-msal.

Hi @dnk8n
Thank you so much for taking the time to write this detailed report, and to share your feedback with us. It really helps!
I'm sorry we took so long to answer.

I admit I probably need to dig a bit deeper into the difference between the accessToken and the idToken, to see which one we should use as default.
In case both are relevant, we could also add an option to the httpClient to let the user choose.
I'll look into that.

In the meantime, again, thank you so much for your feedback!

from ra-auth-msal.

According to

• AzureAD/microsoft-authentication-library-for-objc#683
• https://stackoverflow.com/questions/58459758/id-tokens-vs-access-tokens-in-implicit-grant-flow

it seems that for SPAs, only the accessToken should be needed.
I'm not sure why you needed the idToken in your case. (although it is true that in the resources I listed, some users say that some MS endpoints still need the idToken for some reason...)

Hence, I won't add an option to support it, but I will mention in the docs that we use the accessToken by default and that the user should provide their own httpClient if they need something else.

In any case, thanks for bringing this to our attention 🙂

from ra-auth-msal.