Hi Patryk, first of all I rly like your article. It is pretty short and explanatory.
I still have a question which we have on our project as well.
As I understand the ID Token is emmited to the audienc which is oftend the client_id of the reqeusting client (in your case SPA). Is it then correct that your backend (apwish) will receive and read the token which was emitted for differend party?
Should not it be rather that your app would request accesstoken (via code flow) and authorize the user on the backend which will then on behalf of the user request his ID token from OP?
This debate was started after reading auth0's doc:
Do not use ID tokens to gain access to an API. Each token contains information for the intended audience (which is usually the recipient). According to the OpenID Connect specification, the audience of the ID token (indicated by the aud claim) must be the client ID of the application making the authentication request. If this is not the case, you should not trust the token. Cite from: auth0.com
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Hi Patryk, first of all I rly like your article. It is pretty short and explanatory.
I still have a question which we have on our project as well.
As I understand the ID Token is emmited to the audienc which is oftend the client_id of the reqeusting client (in your case SPA). Is it then correct that your backend (apwish) will receive and read the token which was emitted for differend party?
Should not it be rather that your app would request accesstoken (via code flow) and authorize the user on the backend which will then on behalf of the user request his ID token from OP?
This debate was started after reading auth0's doc: