Skip to content

Latest commit

 

History

History
30 lines (26 loc) · 5.23 KB

terminology.md

File metadata and controls

30 lines (26 loc) · 5.23 KB
Raw

Terminology

  • Authentication Provider: The provider is the Authentication Service that you are using to authenticate your users. For example, you can authenticate with OAuth2 using the OAuth2 (Generic) provider, or use WordPress credentials with the PASSWORD provider.
  • ProviderConfig: The ProviderConfig is an extendable PHP class that defines the configuration for a specific provider. It is used to generate the client, and to map the resource owner data to a WordPress user.
  • Client: The Client is the application instance that you are using to authenticate your users. Clients are generated during the GraphQL mutation, using the WPGraphQL\Login\Auth\ProviderConfig\ProviderConfig class. Each ProviderConfig has its own client which can be feched by quering the RootQuery.loginClient.
  • OAuth2 & OpenID Connect: OAuth 2.0 is an authorization framework that enables applications to obtain limited access to user accounts on an external HTTP Service, such as Facebook, GitHub, or Google. OpenID Connect is an authentication layer on top of OAuth 2.0. It allows clients to verify the user identity identity and obtain basic profile information.
    Headless Login for WPGraphQL uses the League OAuth2 Client library to handle the OAuth 2.0 / OpenID Connect authentication flow. You can also easily add your support for your own OAuth 2.0 / OpenID Connect provider using an existing League OAuth2 Provider, or even a use a custom Provider or a wholly different authentication method by extending WPGraphQL\Login\Auth\ProviderConfig\OAuth2Config class.
    • Authorization URL: The Authorization URL is the URL that the user is redirected to in order to authenticate with the provider. It is generated by the ProviderConfig class (and fetchable from RootQuery.loginClient).
    • Redirect URI: The Redirect URI is the URL that the user is redirected to after authenticating with the provider. In most headless applications, this will be the API route that takes the authentication response and passes it to the login/linkUserIdentity mutations.
    • Resource Owner: The Resource Owner is the user that you are authenticating via the provider. For example, if you are authenticating a user using Facebook, the Resource Owner is the user that is logging in with their Facebook account. The resource owner data is used to match the user to an existing WordPress user, or create a new WordPress user if none exists.
  • Tokens and Secrets:
    • JWT: A JSON Web Token (JWT) is an encrypted string that contains a payload of data. The JWT is signed using a secret key, and can be verified using the same secret key.
    • Authentication Tokens: Authentication tokens are short-lived JWT used to authenticate a WordPress user without requiring a username and password. They are signed using the Site Secret, and can be verified using the same secret. Authentication tokens should be used in the Authorization header of the GraphQL request, and are used to authenticate the user for the duration of the request.
    • Refresh Tokens: Refresh tokens are long-lived JWT used to refresh an authentication token. They are signed with a User Secret, and are used to generate a new authentication token when it expires.
    • Site Secret: The Site Secret is a special secret key that is used to sign all authentication tokens. If it is not manually defined, it will be generated. The Site Secret should be kept secret, and should not be shared with anyone. Changing the Site Secret will invalidate all existing authentication tokens.
    • User Secret: The User Secret is a special secret key that that is used to provide an additional layer of security when validating an authentication or refresh token. It is generated when a user is created. Changing the User Secret will log the user out of all devices, and invalidate all of their existing authentication and refresh tokens.
  • CORS & Access Control Headers: Cross-Origin Resource Sharing (CORS) is a mechanism that allows restricted resources on a web page to be requested from another domain outside the domain from which the first resource was served.
    • Access-Control-Allow-Origin: The Access-Control-Allow-Origin header determines whether a request is allowed to access the API. It can be set to a specific domain, or set to * to allow all domains.
    • Access-Control-Allow-Credentials: The Access-Control-Allow-Credentials header determines whether a request is allowed to send cookies with the request. It can be set to true to allow cookies, or false to disallow cookies.
    • Access-Control-Allow-Headers: The Access-Control-Allow-Headers header determines which headers are allowed to be sent with the request.
    • Access-Control-Expose-Headers: The Access-Control-Expose-Headers header determines which headers are allowed to be exposed to the client. Be careful not to expose sensitive information, such as custom authentication tokens.

Next Steps