OAuth authentication¶
You can use OAuth2 authentication to securely connect to external services.
Ibexa DXP uses an integration with knpuniversity/oauth2-client-bundle
to provide OAuth2 authentication.
To enable OAuth2, you need to:
- enable and configure an OAuth2 provider
- add a guard authentication to your firewall configuration
- select one of the existing resource owner mappers, or implement your own one
OAuth2 provider configuration¶
To configure the OAuth2 provider, add it under the oauth2 key in SiteAccess-aware configuration, for example:
1 2 3 4 5 6 | |
Details of the configuration depend on the OAuth2 provider that you want to use.
For sample configurations for different providers,
see knpuniversity/oauth2-client-bundle configuration.
Firewall configuration¶
Firewall configuration is located in config/packages/security.yaml under security.firewalls.
The guard.authenticators setting specifies the Guard authenticators to use.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 | |
Resource owner mappers¶
Resource owner mappers map the data received from the OAuth2 provider to user information in the Repository.
Resource owner mappers must implement the Ibexa\Platform\Contracts\OAuth2Client\ResourceOwner\ResourceOwnerMapper interface.
There are four existing implementations of ResourceOwnerMapper:
ResourceOwnerToExistingUserMapperis the base class that is extended by the following mappers:ResourceOwnerIdToUserMapperdoes not create a new user, but loads a user (resource owner) based on their identifier.ResourceOwnerEmailToUserMapperdoes not create a new user, but loads a user (resource owner) based on their email.
ResourceOwnerToExistingOrNewUserMapperchecks if the user exists and loads them if they do. If they do not, the mapper creates a new user in the Repository.
To use ResourceOwnerToExistingOrNewUserMapper you need to extend it in your custom mapper.
See Adding login through external service for an example of creating a mapper
that extends ResourceOwnerToExistingOrNewUserMapper.
OAuth User Content Type
When you implement your own mapper for external login, it is good practice to create a special User Content Type for users registered in this way.
This is because users who register through an external service do not have a separate password in the system. Instead, they log in by their external service's password.
To avoid issues with password restrictions in the built-in User Content Type, create a special Content Type (for example, "OAuth User"), without restrictions on the password.
This new Content Type must also contain the User (ezuser) Field.