Closed nirinchev closed 6 years ago
Additionally, for the isAdmin and any later fields (new permissions API?), namespaced tokens should be accepted by defining an URL prefix like "http://mydomain.com/isAdmin".
My line of thinking was to add optional properties that point to the field name in jwt. Something like:
export interface JwtAuthProviderConfig {
publicKey: string;
userIdFieldName?: string; // defaults to userId
isAdminFieldName?: string; // defaults to isAdmin
}
Then, if you wanted to override these, you'd use it like:
const provider = new JwtAuthProvider({
userIdFieldName: 'http://mydomain.com/userId',
isAdminFieldName: 'http://mydomain.com/isAdmin'
});
Do you feel that is too cumbersome? My reasoning was that it's possible that people already have some fields defined that don't match our expectations so I didn't want to paint ourselves into a corner again :)
For the situation now that sounds definitely good but would't it get complicated with the evolution of the Permissions API, when there is more than the "isAdmin" flag? If that is taken into account with this solutions that would be 100% fine since i could just use the "user_id" from auth0 and then "mydomain.com/isAdmin" for the admin, without creating my own id field making it unnecessarily big.
auth0 doesn't allow non-namespaced properties in JWT and it's likely people's existing implementations are not going to conform to our expectations. Add configuration options to allow developers to override the name of the property that identifies the user id. Reported on the forums.