XIVAuth makes use of JWTs for purposes of attestations, such as proving ownership over a character. The JWT implementation that XIVAuth exposes requires some special considerations in order to keep consumer applications secure. This page documents those considerations, as well as general guidance for ensuring safety while using Attestation JWTs.
<aside> 🔥 This document is still being written, and serves as loose notes right now.
</aside>
kid
field in their header to denote which key signed the JWT. Consumers will need to use this kid
to find the public key as exposed by JWKS.Ed25519
JWTs, be sure you’re only verifying Ed25519
as an algorithm type!
/verify
endpoint will have this taken care of for them. XIVAuth will find the kid
that generated the key and verify that the algorithm used is allowed for that kid
. That is, a kid
that refers to an RSA-only key will only verify against the RSA algorithms.kid
instead, and verify your signature types appropriately.
kid
will never have HS256
as a keypair.HS256
et al), the /verify
endpoint is mandatory.XIVAuth JWT attestations are normal (standards-compliant) JWTs, with the following properties:
kid
field in the JWT header will always be set with the name of the key that signed that JWT.iat
and exp
field will always be present in the JWT body, with a low TTL for expirations. Clients should not implement any skew for these fields.XIVAuth currently supports the following algorithms:
HS256
, HS384
, HS512
RS256
, RS384
, RS512
PS256
, PS384
, PS512
ES256
, ES384
, ES512
EdDSA
, ED25519
(not in spec)Consumers are recommended to use the EdDSA
algorithm when possible, with RS256
or PS256
serving as a fallback. In most cases, if an algorithm is not specified, XIVAuth will provide an EdDSA
JWT.