Auth0\SDK\API\Authentication
class, which houses the methods you can use to access the Authentication API directly. Please note that this interface is intended for more advanced applications and in general does provide a means of keeping track of user sessions. For most use cases, you’ll want to work with the Auth0 base class.
In this article, you’ll find examples of common authentication operations.
Prerequisites
The documentation below assumes that you followed the steps in the Installation and Getting Started sections, and continue off from the code provided there.Authorization Code Flow
An Authorization Code Flow is the basic way to grant users access to your application. This flow is the same one used on the Auth0-PHP Basic Use page. If you need more granular control over the login or callback process, this section walks through how to use the Authentication API directly. Users must authenticate with Auth0 to generate the authorization code. This is done by redirecting to the/authorize
endpoint for your tenant domain. The following code would appear on a page that requires authentication:
- We check if there is an authenticated user state stored in our custom session handler. Your application might handle user sessions differently.
- If there is no session, then we need to log the user in by redirecting them to the Universal Login Page.
- We set a state value with the login request and then verify that value when the code is returned on the callback URL. We’re storing this in our PHP session under the ‘state’ key.
- The
getLoginLink()
call builds the correct/authorize
link with the correct response type (code
in this case), redirect URI (wherein the application we will handle the response, explained below), and state (from above). - We then redirect to this URL and wait for the user to be redirected back to us.
- We look for a
code
parameter in a request query. If it’s missing, we abort authentication. - We check to make sure we have a
state
value and make sure it matches the same one we generated. This is important to avoid CSRF attacks. - We attempt a code exchange with the c
odeExchange()
call, making sure to pass in thecode
Auth0 gave our application when it returned the authenticating user back to us. - If this succeeds, we know the exchange was successful, and we have an ID Token and an Access Token among other potential values.
- We validate the ID Token and use the claims for the user identity.
- If this last step succeeds, we store the user and redirect back to our sensitive data.
Client Credentials Flow
The Client Credentials Flow gives an application access to a specific API based on the scopes set in the dashboard. This is how applications can, for example, make calls to the . Successful authentication will result in an being issued for the API requested. First, turn on the Client Credentials grant on then Advanced settings > Grant Types tab on the Application settings page. Next, authorize the Application for the API being used on the Machine to Machine Applications tab on the API’s Settings page. Make sure all necessary scopes are selected (but no more) and Update. Switch back to the Settings tab and copy the Identifier value. This needs to be added to aAUTH0_MANAGEMENT_AUDIENCE
key in your .env
file.
Request an Access Token for the API using the example below:
Single Sign-on Logout
While destroying the local session with asession_destroy()
would be sufficient in de-authenticating a user from your application, you should close your end user’s session with Auth0 as well. This ensures that the next time the user sees an Auth0 login form, they will be required to provide their credentials to log in.
First, determine where the user should end up after the logout has completed. Save this in the Auth0 Application settings in the “Allowed Logout URLs” field. Also, add an AUTH0_LOGOUT_RETURN_URL
key with this URL as the value in your .env
file.
Add the following to your application logout code: