Optional clientOptional clientOptional clientProtected configurationOptional useMTLSThis is the flow that regular web apps use to access an API.
Use this endpoint to exchange an Authorization Code for a Token.
See: https://auth0.com/docs/api/authentication#authorization-code-flow44
const auth0 = new AuthenticationApi({
domain: 'my-domain.auth0.com',
clientId: 'myClientId',
clientSecret: 'myClientSecret'
});
await auth0.oauth.authorizationCodeGrant({ code: 'mycode' });
PKCE was originally designed to protect the authorization code flow in mobile apps, but its ability to prevent authorization code injection makes it useful for every type of OAuth client, even web apps that use client authentication.
See: https://auth0.com/docs/api/authentication#authorization-code-flow-with-pkce45
const auth0 = new AuthenticationApi({
domain: 'my-domain.auth0.com',
clientId: 'myClientId',
clientSecret: 'myClientSecret'
});
await auth0.oauth.authorizationCodeGrantWithPKCE({
code: 'mycode',
code_verifier: 'mycodeverifier'
});
This is the OAuth 2.0 grant that server processes use to access an API.
Use this endpoint to directly request an Access Token by using the Client's credentials (a Client ID and a Client Secret or a Client Assertion).
See: https://auth0.com/docs/api/authentication#client-credentials-flow
const auth0 = new AuthenticationApi({
domain: 'my-domain.auth0.com',
clientId: 'myClientId',
clientSecret: 'myClientSecret'
});
await auth0.oauth.clientCredentialsGrant({ audience: 'myaudience' });
Optional initThis information is typically received from a highly trusted public client like a SPA*. (*Note: For single-page applications and native/mobile apps, we recommend using web flows instead.)
See: https://auth0.com/docs/api/authentication#resource-owner-password
const auth0 = new AuthenticationApi({
domain: 'my-domain.auth0.com',
clientId: 'myClientId'
clientSecret: 'myClientSecret'
});
await auth0.oauth.passwordGrant({
username: 'myusername@example.com',
password: 'mypassword'
},
{ initOverrides: { headers: { 'auth0-forwarded-for': 'END.USER.IP.123' } } }
);
Set the'auth0-forwarded-for' header to the end-user IP as a string value if you want brute-force protection to work in server-side scenarios.
This is the OAuth 2.0 extension that allows to initiate an OAuth flow from the backchannel instead of by building a URL.
See: https://www.rfc-editor.org/rfc/rfc9126.html
const auth0 = new AuthenticationApi({
domain: 'my-domain.auth0.com',
clientId: 'myClientId',
clientSecret: 'myClientSecret'
});
await auth0.oauth.pushedAuthorization({ response_type: 'id_token', redirect_uri: 'http://localhost' });
Optional initUse this endpoint to refresh an Access Token using the Refresh Token you got during authorization.
See: https://auth0.com/docs/api/authentication#refresh-token
const auth0 = new AuthenticationApi({
domain: 'my-domain.auth0.com',
clientId: 'myClientId'
clientSecret: 'myClientSecret'
});
await auth0.oauth.refreshTokenGrant({ refresh_token: 'myrefreshtoken' })
Protected requestOptional initOverrides: RequestInit | InitOverrideFunctionUse this endpoint to invalidate a Refresh Token if it has been compromised.
The behaviour of this endpoint depends on the state of the Refresh Token Revocation Deletes Grant toggle. If this toggle is enabled, then each revocation request invalidates not only the specific token, but all other tokens based on the same authorization grant. This means that all Refresh Tokens that have been issued for the same user, application, and audience will be revoked. If this toggle is disabled, then only the refresh token is revoked, while the grant is left intact.
See: https://auth0.com/docs/api/authentication#revoke-refresh-token
const auth0 = new AuthenticationApi({
domain: 'my-domain.auth0.com',
clientId: 'myClientId'
clientSecret: 'myClientSecret'
});
await auth0.oauth.revokeRefreshToken({ token: 'myrefreshtoken' })
Optional init
OAuth 2.0 flows.