3 ms·
Look at the JWT, take the issuer claim, take the .well-known config off that url, and you have keys. Match that against the known permanent issuer you expected,
by hirsin 8y ago
Look at the JWT, take the issuer claim, take the .well-known config off that url, and you have keys. Match that against the known permanent issuer you expected, and verify the signature of the JWT against the keys. If you're accepting things that aren't JWTs then you're not doing oauth.
- arkh 8y ago> If you're accepting things that aren't JWTs then you're not doing oauth. As a resource server: https://tools.ietf.org/html/rfc6749#page-10 https://tools.ietf.org/html/rfc6749#page-10 Access tokens don't have to be JWT. And some OpenID authentication server give opaque tokens: your resource server has to know how to call it to check the token and get some user infos if available.
- hirsin 8y agoYes, I misread and typo'd.
- dwaite 8y agoOnly OpenID Connect has a guarantee that it will issue a JWT token (and only the id_token). OAuth allows access and refresh tokens to be opaque to the client - e.g. either: - a value only the AS understands (in which case the protected resources will need to use an API to introspect them) - a format that both the AS and protected resources can understand (such as a legacy crypto format, a COSE token, or a database key) If your client has to pull apart an access token to extract information and make a decision, you are doing OAuth wrong. In particular, that client code will never work against another AS, and it is more fragile than normal against changes on the AS.
- hirsin 8y agoYes, I misread and typo'd, thinking OP was talking id_tokens and OIDC. Completely correct on the last para, I spend quite a bit of time convincing partners of this.