- Implements PSR-15
- When an token can't be found the returned error response by the resource server middleware is now in a similar format to other errors. This might BC if your client depends on the error key in the message.
- Added an server option so the request attribute for tokens can be configured
BC! Pre release of a completely rewritten library. It focusses on core OAuth2 functionality and has been decoupled from persistence. If you still need the previous implementation - which is considered EOL - see the legacy-0.7 branch
- PHP7+ only
- 100% test coverage
- Uses Zend\Diactoros to generate PSR-7 (Http Message) implementation.
- Uses PSR-11 (Container) for dependency injection containers.
- Eventing has been removed
- Persistence has been decoupled, see our doctrine integration ZfrOAuth2ServerDoctrine
- Provides 5 Services
- ZfrOAuth2\Server\Service\AccessTokenService
- ZfrOAuth2\Server\Service\AuthorizationCodeService
- ZfrOAuth2\Server\Service\ClientService
- ZfrOAuth2\Server\Service\RefreshTokenService
- ZfrOAuth2\Server\Service\ScopeService
- Provides 4 PSR7 Middleware's which are really nice but optional
- ZfrOAuth2\Server\AuthorizationServerMiddleware
- ZfrOAuth2\Server\ResourceServerMiddleware
- ZfrOAuth2\Server\RevocationRequestMiddleware
- ZfrOAuth2\Server\TokenRequestMiddleware
- Now properly triggers an
EVENT_CODE_CREATED
event instead ofEVENT_CODE_FAILED
when response is between 200 and 399 (previously, as 302 Redirect used to trigger a failed event, although it created an authorization code).
-
[BC] PHP minimum version has been bumped to 5.5. As a consequence, Zend\Crypt dependency has been removed as some of features are built-in into PHP 5.5.
-
[BC] Instead of Zend\Http requests and responses, the module now uses PSR7 requests and responses, for increased compatibility. If you are using the ZF2 module, this should be completely transparent to you.
-
[BC] Contrary to Zend\Http requests and responses, PSR7 are stateless. If you are using events to modify the response, you will need to use a different way.
In ZfrOAuth2Server 0.6:
public function tokenCreated(TokenEvent $event)
{
// We can log the access token
$accessToken = $event->getAccessToken();
// ...
// Or we can alter the response body, if we need to
$body = $event->getResponseBody();
$body['custom_field'] = 'bar';
// Update the body
$event->setResponseBody($body);
}
In ZfrOAuth2Server 0.7+:
public function tokenCreated(TokenEvent $event)
{
// Get the response
$response = $event->getResponse();
// ...
// Response is a PSR-7 compliant response, so you modify it
$response = $response->withHeader(...);
// Do not forget to set back the response, as PSR-7 are immutable
$event->setResponse($response);
}
- Interfaces for ResourceServer and AuthorizationServer has been added, for easier testing.
- In previous versions, ZfrOAuth2 would trigger an "InvalidAccessTokenException" if you'd try to call the
getToken
when no token was specified in either Authorization header or query param. Now, ZfrOAuth2 will simply return null (because no token was explicitly set). However, this exception will be trigger IF an access token is indeed given, but does not exist in your database, is expired or does not match scopes.
- Support for token revocation by implementing RFC7009 specification
- Allow multiple redirect URI for client (there is a minor table schema change, as a consequence)
- Fix a potential security issue by being more restrictive on the redirect URI when creating an authorization code. Now, if someone send a custom redirect_uri in the query params, the OAuth2 server will first check if the given redirect URI is in the list of the authorized redirect URIs by the client. If that's not the case, an InvalidRequest exception will be returned, and no authorization code will be generated.
- Add support for the ZF2 event manager. You can now attach listeners that are called whenever a new authorization code is created or failed, or when a new access token is created or failed.
- [BC] The
isRequestValid
from the ResourceServer is now gone in favour of a simpler approach: you just need to call thegetAccessToken
from the ResourceServer (with optional scopes), and null will be returned if the token is either expired, does not exist or does not match given scopes.
- Tokens do not contain \ and / characters anymore (as it can lead to problems when the token is passed as a query param).
- First release!