Oauth2-server: How does token verification and JWT work?

[JasonTheAdams]

Getting this going on a vanilla PHP project and I'm rather confused as to how oauth2-server and oauth2-client work together. On this particular project the only initial grant that will be supported is the client grant, so very simple.

The token request endpoint is set up and works. What confuses me is that the access_token is an SHA-256 signed JWT. In my case auth and resource server are the same, as I understand the keys for are this distinction. So when a client requests a token and receives a JWT access token, what happens? My understanding was that it would store the token and provide it with future requests, but in this massive form? And how could the oauth2-server validate the token as the token is stored in a non-encrypted form?

I'm sure I'm jut not seeing how the pieces come together. These libraries are great, but proper documentation would be incredible. I would appreciate if someone could please help point me in the right direction and clear up my misunderstanding.

Thank you!

[Sephster]

Hi @JasonTheAdams. The client will store the access token and pass it back on future requests. The resource server validates the JWT by checking that the signature is as expected. The JWT is made up of three parts:

• The header
• The payload
• The signature

The signature is created by the auth server, by encoding the header and payload along with a secret known only to the auth server.

This allows the auth server to ensure that the payload and header have not been tampered with since they were issued by the server. It doesn't matter that the JWT can be read by others as it can't be tampered with. If someone changes the payload or header, it won't match the signature and will be rejected by the resource server.

The main thing you have to do is ensure that the access token is not given to anyone else. Because it is a bearer token, anyone possessing it will have access to the protected resources. I hope this answers your question but if you have any follow ups please give me a shout.

[JasonTheAdams]

Ahah! I get it now! 😄

Thank you for breaking down the JWT, that made me realize that I didn't fully understand the JWT standard, so I did some more homework. Now it makes sense. I also thought the JWT was validated on the client side, which it's not; it's validated on the resource server (which in my case is the same server as the authentication server).

This is a tangent question, but if you don't mind I'd be interested in your input. The JWT validates that the client is who they say they are and cleared to have access to the resources they're requesting. But what's a recommended way of offering some security in terms of the payload sent from the client to the resource server? In my case, the client may be passing somewhat sensitive information. The resource server is required to have an SSL certificate, but not the client. Is this enough? Should some form of end-to-end encryption be used? In which case do you per chance have a recommendation?

Thank you for any and all advice!

[Sephster]

Yes, this should be enough. As long as you are communicating over https, which this server and the OAuth 2 spec mandate, it should be fine. One caveat is if you are using a native app such as a desktop app. If you are, you probably need to use PKCE as well but if it is website to website, there should be no additional requirements.

[JasonTheAdams]

Got it, thank you! Should I require that the client server use https, or is it _enough_ that the authentication and resource servers use it? There's a good chance many client sites will be on https, but I'm deciding whether it should be a requirement. Thank you for your advice!!

[Sephster]

Sorry, ignore my previous response. Both endpoints should be accessed over https to avoid man in the middle attacks so both your client and auth/resource server should be served via https.

[JasonTheAdams]

Got it! I have this working, now. Thank you!