Closed andrewbonney closed 4 years ago
From the existing spec, token attributes are used as follows:
iss
: Address of the Authorization Server which issued the token
sub
: A reference to the user who authorised the generation of the access token
client_id
: A reference to the client which holds the token
Of the above, the only one which makes sense to use in the context of protecting a client's registered IS-04 resources is the client_id
as this is intrinsically linked to the client, and can't change if a new user or server authorises that client in the future.
Based on that I'll adjust this document and the IS-10 spec to ensure that one of client_id
or OIDC's azp
are present and checked against.
IS-10 made the token
client_id
optional for compatibility reasons, but this is depended upon by BCP-003-02. Either addingazp
claim support or using thesub
may be ways around this.In addition, the text in BCP-003-02 needs to be clearer that any sub-resources of a Node which a registered/updated/deleted need to be checked against the
client_id
which was used for the initial Node registration.