Node.js implementation of issuer REST APIs for OAuth3
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
 
AJ ONeal e9d530f2a0 change sponsorship 6 years ago
CHANGELOG v1.2.1 7 years ago
LICENSE add standard files 7 years ago
README.md change sponsorship 6 years ago
accounts.js use db to retrieve subs 7 years ago
assets.js fudge assets handling for now 7 years ago
common.js made it possible for a user to have same `sub` for multiple `azp`'s 7 years ago
grants.js made it possible for a user to have same `sub` for multiple `azp`'s 7 years ago
jwks.js made it possible for a user to have same `sub` for multiple `azp`'s 7 years ago
models.js use db to retrieve subs 7 years ago
package.json v1.2.1 7 years ago
rest.js use db to retrieve subs 7 years ago

README.md

issuer@oauth3.org (js)

| oauth3.js | issuer.html | issuer.rest.walnut.js | issuer.srv | Sponsored by ppl

Implementation of server-side RESTful OAuth3 issuer APIs.

These are the OAuth3 APIs that allow for creation and retrieval of public keys used for signing identity tokens.

"issuer" is somewhat of a misnomer from the OIDC breakdown of authentication / authorization parties. What we mean by "issuer" here is actually more like "notary" or "authorized verifier". However, since the "iss" field is already standardized, we keep that name for consistency.

What's to be implemented:

Looking at https://oauth3.org/.well-known/oauth3/directives.json, the core issuer components are these:

api:                    api.:hostname
authorization_dialog    #/authorization_dialog
logout                  #/logout
publish_jwk:            :scheme//:hostname/api/issuer@oauth3.org/jwks/:sub
retrieve_jwk:           :scheme//:hostname/api/issuer@oauth3.org/jwks/:sub/:kid.json
grants:                 :scheme//:hostname/api/issuer@oauth3.org/grants/:sub/:azp?
credential_meta:        :scheme//:hostname/api/issuer@oauth3.org/logins/meta/:type/:id
credential_otp:         :scheme//:hostname/api/issuer@oauth3.org/otp

No access_token endpoint is strictly necessary. Since clients can create and manage their identity, the can sign create their own tokens. If the identity is stored on the issuer, then the issuer can also sign tokens. Doing so gives full control of all resources owned by the subject "sub" to the issuer "iss".

create_sub:       :scheme//:hostname/api/issuer@oauth3.org/subs/:secret/:sub

And here are some others that are useful, but could be implemented differently without breaking the protocol.

credential_create:  :scheme//:hostname/api/issuer@oauth3.org/logins
credential_meta:    :scheme//:hostname/api/issuer@oauth3.org/logins/meta/:type/:id
credential_otp:     :scheme//:hostname/api/issuer@oauth3.org/otp

subject

The sub field must be sha256(secret + ':' + azp).

Example:

var secret = '8f7acd369764df342d1581872ff5f70fcc261aa116b3c41dee7ca3474ee2020f' // cryto.randomBytes(32).toString('hex')
var sha256 = cryto.createHash('sha256');
sha256.update(new Buffer(secret, 'hex'));
sha256.update(':' + 'example.com');

var sub = sha256.digest('hex');

This way any issuer can transfer ownership of identity to any other issuer and deterministically reproduce the ppid by virtue of the secret identity of the subject and the public identity of the authorized party.

JWKs

We want the users to have the option of signing tokens using keys on their own devices. This requires having a place to store the public half of those keys on a server that can then server the public keys to resource providers for signature verification.

Publishing a JWK

  • URL :scheme//:hostname/api/issuer@oauth3.org/jwks/:sub
  • Method POST
  • Url Params
    • sub: The subject using the issuer hostname as the azp
  • Body Params: The body should be a JSON object representing a JWK.

Retrieving a JWK

  • URL :scheme//:hostname/api/issuer@oauth3.org/jwks/:sub/:kid.json
  • Method GET
  • Url Params

Currently only EC and RSA key storage is supported. All provided parameters will be stored in the database, but only generic JWK parameters and parameters specified as part of the public key for the kty by the JWA will be given back by the GET request. This is to avoid compromising a key if the private portion or any other potentially sensitive fields are given to us.

Grants

Grants represent the list of resources the user has allowed a party to access. We store those permissions on the server so that users will not have to grant the same privileges multiple times on different machines. We also store the subject between the user and the azp to allow us to only serve public keys associated with the correct user when retrieving JWKs.

Saving/Modifying Grants

  • URL :scheme//:hostname/api/issuer@oauth3.org/grants/:sub/:azp
  • Method POST
  • Url Params
    • sub: The subject using the issuer hostname as the azp
    • azp: The authorized party the grants are for
  • Body Params
    • sub: The subject using azp from the url
    • scope: A comma separated list of the permissions granted
  • Response: The same object returned when retrieving single grants

Retrieving Grants

  • URL :scheme//:hostname/api/issuer@oauth3.org/grants/:sub/:azp
  • Method GET
  • Url Params
    • sub: The subject using the issuer hostname as the azp
    • azp: The authorized party the grants are for
  • Response
    • sub: The same sub from the url
    • azp: The same azp from the url
    • azpSub: The sub for the azp
    • scope: A comma separated list of the permissions granted
    • updatedAt: The ms timestamp for the most recent change to the grants

Retrieving All Grants For a User

  • URL :scheme//:hostname/api/issuer@oauth3.org/grants/:sub
  • Method GET
  • Url Params
    • sub: The subject using the issuer hostname as the azp
  • Response: An array of objects with the same values as the single grant get response.