dnk8n
commented
1 year ago Oh nooo. I had the .env in the wrong directory. It was in src/ and needed to be placed one level up, ../
Closed dnk8n closed 1 year ago
dnk8n
commented
1 year ago Oh nooo. I had the .env in the wrong directory. It was in src/ and needed to be placed one level up, ../
dnk8n
commented
1 year ago 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.
slax57
commented
1 year ago 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!
slax57
commented
1 year ago According to
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 :slightly_smiling_face:
dnk8n
commented
1 year ago 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)
Update: Found the issue, see next comment
Making use of this library in an existing project
There are a few things unclear to a new user of such a library... maybe this issue could be used to clear some things up (i.e. some additions required in docs to smooth things over)
Problem 1:
ra-auth-msal interacts with Azure AD, auth happens, and we get a valid
Authorizationheader withBearer ${TOKEN}, how to ensure that it is in a format that matches your data provider?Answer: I provided an answer to the problem I had getting started with this library in the comment below
Original Issue
I looked for a discussion section (please let me know if there is a better place for this message)...
I might just be missing something super obvious.
I started by following the instructions, and I get the sample app working beautifully.
But when I try to cherry-pick the relevant parts to a new project, no matter what I try it doesn't work. Console errors usually include :
I also tried the much more basic implementation as in your docs, but similar issues.
Below are the changes I attempted:
MSAL related commit: