Long time software architect, CTO Authress, creating application security plug-ins for any software application with Authress. Talk to me about security in microservices or service authorization.
I think there is some good stuff in this article, although I will point out the following no-so-great advice:
The Signed token is generated by combining the encoded JWT header and Payload and it is signed by using an encryption algorithm like HMAC SHA–256
Only EdDSA should be used, HMAC never, and RSA rarely. If your auth provider isn't using EdDSA, you actually want to switch providers.
Access token must never be used for authentication. Access tokens cannot tell if the user has authenticated. The only user information the access token processes is the user id, located in sub-claims.
This is nonsensical, access tokens are generated as a result of authentication. Saying they must not be used for authentication, doesn't make sense. Further, the holder of an access token has authenticated! Also the access token can contain any information, there are no limitations on what can be in the access token.
The IdToken token authenticates the user to the application. The audience of this token is set to the application’s identifiers, which means a specific application should consume the token.
This is just wrong, the ID token is only used to contain OpenID user information, it has no intended purpose, and should never be used for any type of security related action.
Refresh tokens are used only for offline access, web clients should never be requesting or using these. These are meant for service clients only.
Refresh tokens can be used for grant types – authorization code and password credentials grant.
The password credentials grant should never be used, and refresh tokens must and can only be used with refresh_token grant type.
For a more advanced info on the topic I recommend something like this FAQ which has a lot of JWT based answers.
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.
I think there is some good stuff in this article, although I will point out the following no-so-great advice:
Only EdDSA should be used, HMAC never, and RSA rarely. If your auth provider isn't using EdDSA, you actually want to switch providers.
This is nonsensical, access tokens are generated as a result of authentication. Saying they must not be used for authentication, doesn't make sense. Further, the holder of an access token has authenticated! Also the access token can contain any information, there are no limitations on what can be in the access token.
This is just wrong, the ID token is only used to contain OpenID user information, it has no intended purpose, and should never be used for any type of security related action.
The password credentials grant should never be used, and refresh tokens must and can only be used with
refresh_tokengrant type.For a more advanced info on the topic I recommend something like this FAQ which has a lot of JWT based answers.