[Auth bug] 500 instead of 401 when invalid auth token (JWT) is provived about fastapi_msal HOT 5 CLOSED

Hi @rmwesley - thank you for that very much detailed description.
The issue is clear and for some reason missed that before.
I made the change and will publish it upon the next version 🙏

from fastapi_msal.

De nada @rmwesley
As this issue is now marked as closed I propose to open few new ones.
It seems to me like you are referring to different topics so can you make sure each has its own topic?
Will help me to better answer them.
The first is about the MSAL JWT token, I will look into that once I can better understand the issue / concern.
The second is about updating the documentations which are long past due... probably my next challenge here 😅
The third is about the RBAC which while the PR is simple I'm not sure if that the correct implementation to handle that issue.
We can discuss and I'll elaborate more on that ticket if this is making more sense.

Obrigado 🙏

from fastapi_msal.

Here's an open discussion on FastAPI that may be related to this subject:
tiangolo/fastapi#10615
This discussion is related to a 500 upon trying to authenticate, which is not the same issue as here.
In this case (trying to authenticate) we should get a 400 for invalid credentials (Bad request). Should I open another issue here for this Swagger UI bug?

In our case we should get a 401, since we are not trying to authenticate, we are trying to use the API with an invalid Bearer Token.

from fastapi_msal.

Awesome! Thanks a lot for the reactivity!

I still wanted to comment on the OIDC code for OpendID Connect grant flow.

Apparently, all handling of issued id_tokens on Python MSAL's repo is done under oauth2cli/oidc.py. Correct me if I'm wrong and part of the grant flow is done somewhere else, it is not clear to me.

Most of the raised runtime errors I mentioned above are related to the decoding of the id_token JWT in the middle of the OIDC grant flow.

It may seem unrelated, but I stumbled upon this issue that is still open here.

As ejsyx said regarding JWT decoding, MSAL does not use PyJWT's decode function for decoding JWTs, only for encoding them. This is based on what rayluo commented on this PyJWT decoding issue.

So MSAL decodes the id_token JWT with their own custom-made decode_id_token() function in oauth2cli/oidc.py, right?

This function only decodes the middle part of the id_token, since under oauth2cli/oidc.py MSAL uses a custom decode_part(id_token.split('.')[1]) function, and thus it completely ignores the signature validation, as I mentioned in my original post.

But besides that, OIDC grant flow, that issues an id_token, should not be used for authentication. For auth, an auth code flow is supposed to be done, that ends up issuing an access_token as a grant.

fbelhadi mentioned this issue on this PR arguing Access tokens should be used instead of ID tokens in fastapi_msal (there he mentions the Microsoft Identity Platform docs I keep referring to in my posts haha).

Still, this pull request only mentions RBAC. So the concerns raised by ejsyx will be ignored, right? I mean, if you switch the grant flow and end up with an access_token instead the signature validation issue of id_tokens will become obsolete, right? Or am I just making a crazy soup of unrelated issues?

from fastapi_msal.

Tranquilo kkkk
I was just noting down some things I was analysing, I completely rewrote this message at the very least five times to try and make it make sense, I will keep rewriting it for a while haha.

Also, the "MIP" docs I mentioned are those of Microsoft Identity platform I keep referring to: Access tokens and ID tokens.

from fastapi_msal.