You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The dynamic client auth spec recommends JWTs be signed using public/private key auth.
When presented to the authorization server as part of a
client registration request, the software statement MUST be digitally
signed or MACed using JSON Web Signature (JWS) [RFC7515] and MUST
contain an "iss" (issuer) claim denoting the party attesting to the
claims in the software statement. It is RECOMMENDED that software
statements be digitally signed using the "RS256" signature algorithm
The spec does not describe how one should determine the public key to verify against. One possible way we could do this would be to inspect the iss header, and ping a .well-known address for a public key based of the iss URL. For instance, $iss/.well-known/wp-api.key. We would then need to verify that the iss, client_uri and redirect_uris are all in the same domain.
We could then show on the connection screen that this is an authorized $client_uri app ( or something to that effect ).
The text was updated successfully, but these errors were encountered:
This checks the JWT for an "iss" header. If one is present,
we fetch a public key at that host ".well-known/wp-api/oauth2.pem",
and use that public key to verify the JWT.
If a client is verified we display a "verified" message on the connect screen.
This also adds a new "--sign" flag to the CLI command to generate a signed
software statement.
Fixes#18.
The dynamic client auth spec recommends JWTs be signed using public/private key auth.
The spec does not describe how one should determine the public key to verify against. One possible way we could do this would be to inspect the
iss
header, and ping a.well-known
address for a public key based of theiss
URL. For instance,$iss/.well-known/wp-api.key
. We would then need to verify that theiss
,client_uri
andredirect_uris
are all in the same domain.We could then show on the connection screen that this is an authorized
$client_uri
app ( or something to that effect ).The text was updated successfully, but these errors were encountered: