Download the PHP package mapkyca/known-oauth2-server without Composer
On this page you can find all versions of the php package mapkyca/known-oauth2-server. It is possible to download/install these versions without Composer. Possible dependencies are resolved automatically.
Download mapkyca/known-oauth2-server
More information about mapkyca/known-oauth2-server
Files in mapkyca/known-oauth2-server
Package known-oauth2-server
Short Description Provides an OAuth2 authentication server for API calls
License GPL-2.0
Homepage https://www.marcus-povey.co.uk
Informations about the package known-oauth2-server
OAuth2 Server for Known
EXPERIMENTAL
This plugin provides an OAuth2 Server for Known, allowing users to create applications and allow clients to authenticate themselves for the API and website using an OAuth2 access token.
This plugin is an experimental basic implementation of the spec, so please, kick it around and report any issues you find!
Usage
- Install in your plugins
- Create an application via settings
- Use the appropriate keys in your OAuth2 client
Support
Currently the plugin supports:
- [x] response_type=code
- [x] grant_type=authorization_code
- [x] grant_type=refresh_token
- [x] grant_type=password
- [x] state parameter validation
- [x] scope support
- [x] OpenID Connect
Example usage
To get a code:
You will be bounced to a login + authorisation page if necessary, so follow forwards.
As per the spec, you can omit the , in which case the response will be a straight json encoded blob. If is specified you will be forwarded to the endpoint, with appropriate parameters in the GET fields.
To get a token:
You should get back a json encoded blob with an access token, expiry and refresh token.
To refresh a token:
If your access token has expired, you can update it with the refresh token.
Success will spit back a new access token, refresh token and expiry. It also results in the destruction of the original token.
Accessing the token
On a successful login the token used will be saved to the current session in , you can use this to check scope permissions, application ID and other details.
The scope granted to a given user is also saved against the user object in an array , which is also cross checked on login.
Why not use native signed HTTP?
Natively, Known uses a per-user api key to sign requests, so why not use this?
Of course you can still, and the OAuth2 server doesn't replace that option. In many ways the signed HTTP approach is easier to get going, however...
1) There are many existing libraries for OAuth2 in pretty much every language. 2) With OAuth2 you give different credentials to each application. This means that if you no longer want to allow access from application A, but still want to keep B and C, you can revoke A's tokens specifically.
OpenID Connect
If you include the scope openid
, on success the server will return an OpenID Connect signed JWT in the id_token
field.
This token will include basic information about the authenticated user. If you also ask for email
and profile
scopes as well, you'll get some extra profile information back (email, full name, picture url, username, etc).
You can verify this token against the public key for the application (available from https://yourserver.com/oauth2/CLIENTID/key
)
See
- Author: Marcus Povey http://www.marcus-povey.co.uk
- OAuth2 Spec https://tools.ietf.org/html/rfc6749