Auth Web APIs

Use the Auth interface Web APIs to authenticate for Epic Account Services Web APIs.

11 mins to read

Note: You can also authenticate with the Auth Interface. See Epic Account Services: Auth Interface documentation for more information.

Epic Online Services (EOS) uses the OAuth 2.0 protocol for authentication and authorization, supporting common-use cases for web servers and client-side applications. Epic has also introduced custom grant types for some specific use cases.

Before starting, you will need to obtain OAuth 2.0 client credentials from Epic. These will be in the form of a Client ID and Client Secret, and will be used when requesting an access token from the Epic authorization server. See the Get Started documentation on Epic Account Services for more details.


Game Client on the Epic Games Store

A game client launched from the Epic Games Store will authenticate with Epic’s authorization server using a one-time use exchange code. This exchange code is generated by the Epic Launcher and passed to the game client as a command-line argument.

When the game client is launched, it will make a request to the Epic token endpoint that includes the client credentials and exchange code. The response will include an access token, information about the client and account that were authenticated, and an optional refresh token.

The game client will include the access token on all requests to Epic services. The access token can also be passed to trusted game servers for verification, or for use in service-to-service requests.

When applicable, a refresh token will also be included in the token response. The game client will need to use the refresh token if the access token expires. This typically occurs within 2 hours after the access token is issued.

EGS Client Auth flow

Diagram illustrating Epic Games Launcher authentication flow. Click image to enlarge.

Web Server Applications

For server-side applications, the flow will begin by taking the user through the Epic authorization flow on a web browser so that it can obtain an authorization code. The user will be asked to log in using their Epic Games account, and may be asked to authorize your application. Once authorized, the user agent will redirect back to your web application with an authorization code included as a query parameter.

After the redirect, the web server will make a request to the Epic token endpoint using the client credentials and authorization code. The response will include an access token, as well as information about the client and account that were authenticated.

The web server will include the access token on all requests to Epic services.


As the first step in the authentication flow, the user must authenticate with Epic Account Services. We only support OAuth 2.0 for authentication, with additional custom grant types.

Once the client has the necessary information to request a token (including the exchange code, authorization code, and user credentials), it begins by requesting an access token.

Requesting an Access Token

To request an access token, the client must make an HTTP request to the Epic token endpoint, passing the client credentials (Client ID and Secret) and user credentials.

The Epic token endpoint is If you want to indicate that an access token is no longer needed, use This endpoint implements RFC 7009 - OAuth 2.0 Token Revocation.

The client credentials will be passed in the Authorization header using Basic authorization. This endpoint supports the following post parameters:

Parameter nameDescription
grant_typeThe grant type being used: exchange_code, password, refresh_token, or client_credentials.
deployment_idThe deployment ID that the client is trying to authenticate with. This will impact interactions with other services that require a deployment. If the deployment is not public, only users who have been entitled will be able to log in. For more information on deployments and deployment IDs see Product, Sandbox, and Deployment IDs.
Note: You must use this unique identifier to use the Ecommerce APIs, and to request access tokens used by game clients.
scopeSpace-delimited list of scopes (permissions) that will be requested from the user. For example: basic profile, friends_list, and presence
For the password grant type
Parameter nameDescription
The password grant type can be used during development, but will only be allowed for accounts that are members of the organization that this product is associated with.
Note: The password grant type does not work with 2FA enabled.
usernameThe username (email address) for the account; only used with the password grant type.
passwordThe password for the account; only used with the password grant type.
For the exchange_code grant type
Parameter nameDescription
exchange_codeThe exchange code passed by Launcher to the game client; only used with the exchange_code grant type.
For the authorization_code grant type
Parameter nameDescription
codeThe authorization code received from the authorization server.
For the client_credentials grant type (see Web Authorization )
Parameter nameDescription
client_idThe OAuth Client ID for your application.
client_secretThe OAuth Client Secret for your application.

These parameters should be in the request body. Query parameters will be ignored.

The following snippet shows a sample request using password grant type:

The response contains the following fields:

access_tokenThe access token, which may optionally have a prefix (for example: eg1~[token]). This value should be passed as is in the Authorization header using the Bearer type on any requests to Epic services.
expires_inThe number of seconds until the token expires.
expires_atThe expire date in ISO 8601 format.
account_idThe Epic Account ID for the user that the token was generated for.
client_idThe Client ID which was used to generate this token.
application_idThe Application ID which the Client is associated with.
token_typeThe type of token generated; value will always be bearer.
refresh_tokenThe refresh token will optionally be returned depending on the client configuration. This refresh token can be used to extend a session before or after the access token has expired.
refresh_expiresThe number of seconds until the refresh token expires.
refresh_expires_atThe refresh token expire date in ISO 8601 format.

The following snippet shows a sample response:

The access token should always be passed as is in the Authorization header to Epic services. For example: Authorization: Bearer eyJraWQiOiJ0RkM...

Web Applications

For web and server-side applications, you will need to get an authorization code before requesting an access token. Before using the web authorization, your Epic OAuth Client needs to be configured with a redirect URL.

If you have a userless client setup (i.e. your Client Policy doesn't require a user), you don't need to retrieve any user information and can therefore skip the redirect instructions shown below. You can initialize the client using just the client_credentials.

To initiate the flow, your application will need to redirect the user to the authorization page where they will be asked to log in to their Epic Games account. The authorization URL is:

You can define several redirect URLs with the additional parameter redirect_uri={redirect_uri}. The authorization URL for more than one redirect is:

After the user logs in, they will be redirected back to the configured redirect URL with an authorization code. Your application should use that code to get an Access Token using the authorization_code grant type as described in Requesting an Access Token.

We also support an optional state parameter that can be used to maintain state between the request and the callback, and that is used to prevent cross-site request forgery attacks.

The following is an example redirect after the user is authenticated:

Verifying an Access Token

Offline Verification

The access token is a JWT (JSON Web Token) that includes a header and signature used to validate the authenticity of the token.

Before validating the signature, you will need to fetch a public key published as a JSON Web Key (JWK) from our service. We expose a single endpoint using the JWK Set format that includes all of the current public keys. While the keys are not changed frequently, it is possible that they are rotated at any time.

The JWK endpoint is

Clients fetching the public key should cache them for a reasonable period. While the keys may rotate, a key for a given key ID will not change.

The following snippet shows a sample response from the public keys endpoint:

Online Verification

If offline verification is not an option, you can perform an online verification by calling the token info endpoint with a valid access token. This endpoint implements the Token Introspection specification.

The token info endpoint is

The following snippet shows a sample request to verify a token:

The following snippet shows a sample response from the token info endpoint:

Both access tokens and refresh tokens can be verified using this endpoint.

Game Client on the Epic Games Store

When using a game client connected through the Epic Games Store, the game client must use the exchange_code grant type to get an access token, passing their client credentials and the code passed to the game from the launcher.

During development, you can also use the password grant type, which will allow the game client to authenticate against Epic Services without the launcher integration.

When the game is started by the Epic Games launcher, it will be launched with the following command-line parameters:

AUTH_LOGINUnused for exchange code.
AUTH_PASSWORDThe credentials to be used by the game client. This will include the exchange code that will be passed to the authentication server.
epicappInternal application name.
epicenvEnvironment that this is being launched in (always Prod).
epicusernameDisplay name of the account that is authenticated in the Launcher.
epicuseridEpic Account ID for the account that is authenticated in the Launcher.
epiclocalePreferred locale based on user preference or based on the system language.
epicovtFull path to a file containing Ownership Verification Token information.
epicsandboxidThe sandbox the application was run from. For example, the id associated with your Live, Stage, or Dev sandbox.

The following is a sample of the command line parameters passed by launcher:

Account Information

Once you have an access token, you will be able to make requests to Epic services on behalf of the user. For example, you can make requests to retrieve their display name, or the display names of their friends.

From the Access Token

You can retrieve some information directly from the access token. The token is encoded as a JSON Web Token (JWT), and its header includes information about the type of token and signature it uses, as well as a payload with information about the user, your client, the session, and a signature. We recommend using a library to handle decoding the JWT, but if this is not possible, refer to the JWT specification.

The payload will include the following information:

issstringThe base URI of the Epic Games authentication server that issued the token.
substringThis claim will not be present when using the client_credentials grant type.
audstringThe client ID specified in the authorization request.
iatintegerThe time the token was issued as a UNIX timestamp.
expintegerExpiration time of the token as a UNIX timestamp.
jtistringThe unique identifier for this token.
tstringThe type of token. This should always be epic_id. This replaces the version prefix that we have with EG1 tokens.
scopestringSpace delimited list of scopes that were authorized by the user.
dnstringThe user's display name.
appidstringThe application ID specified in the authorization request.
pfpidstringThe product ID for the deployment that was specified in the token request.
pfsidstringThe sandbox ID for the deployment that was specified in the token request.
pfdidstringThe deployment ID that was specified in the token request.

Using the token from the previous example, we can decode the payload to see that it includes the following:

Fetching Accounts

In addition to the information in the access token, it is possible to request similar information about the logged-in account, or any other account that has interacted with your application.

Due to privacy concerns, you will only be able to request account information for users who have previously provided consent to your application.

The account info endpoint is When calling this endpoint, you will need to specify one or more accountId query parameters for the accounts you are trying to resolve. There is a limit of 50 accounts in a single request.

The following snippet shows a sample request to fetch multiple accounts:

The following snippet is an example response from this request: