I'm designing a JWT authentication workflow for a RESTful API which uses two kinds of tokens:
- Phone token, a short-lived token - issued by completing an One-Time-Password challenge. Its task is to prove "ownership" of a phone. It carries the phone number.
- Access token, a long-lived token - issued by providing a valid phone token. Its task is to provide the identity of the phone owner. It carries the user's ID.
My question is how to structure those two tokens correctly and whether I should use two distinct signing keys for them?
From my understanding the subject (sub
) of the phone token should be the phone number and the subject (sub
) of the access token should be the user's ID. (Edit: I'm not even sure about that, how would the controller know how to interpret the number, i.e looking up the right resource? Wouldn't it be better to use strings like 'phone' and 'identity' for the subject and provide an additional 'id' field?)
What about the issuer field (iss
), should this be something like http://example.com/phone
and http://example.com/identity
?
What about the audience field (aud
)? The phone token has a small audience, i.e only one or two services, should I specify them explictly? Like aud: ['identity', 'xyz']
?
In case of of the access token the audience is quite broad, i.e many services which consume this token, and the audience might grow so I don't want to hardcode them into the token, otherwise I would have to issue new tokens everytime I add a service. How could I circumvent this?
I'd be very glad if you could suggest a possible structure and the reasoning behind it.