DEV Community

OpenID Connect, SPA and backend APIs - Authentication in modern web applications

Patryk Jeziorowski on February 02, 2020

In this post, I’ll try to cover how the process of authentication will look like in Appwish platform. Appwish is made of frontend UI written in Rea...
Collapse
 
miroslavvojtus profile image
Miroslav Vojtuš

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

Collapse
 
tlodderstedt profile image
Torsten Lodderstedt

Thanks for the interesting writeup. One note: you mentioned would follow the new OAuth guidelines, which is great! However, I think you use the code grant type with PKCE and not PKCE alone.

Collapse
 
pjeziorowski profile image
Patryk Jeziorowski

You're welcome:) Good catch, you're right. It's the default when you use Auth0's client lib for SPAs.

Collapse
 
guyeshet profile image
Guy Eshet

great explanation, thanks!

Collapse
 
pjeziorowski profile image
Patryk Jeziorowski

Thanks, you're welcome!