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.
Scenarios
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.
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.
Authentication
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 https://api.epicgames.dev/epic/oauth/v1/token. If you want to indicate that an access token is no longer needed, use https://api.epicgames.dev/epic/oauth/v1/revoke. 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 name | Description |
grant_type | The grant type being used: exchange_code, password, refresh_token, or client_credentials. |
deployment_id | The 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. |
scope | Space-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 name | Description |
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. | |
username | The username (email address) for the account; only used with the password grant type. |
password | The password for the account; only used with the password grant type. |
For the exchange_code grant type | |
| Parameter name | Description |
exchange_code | The exchange code passed by Launcher to the game client; only used with the exchange_code grant type. |
For the authorization_code grant type | |
| Parameter name | Description |
code | The authorization code received from the authorization server. |
For the client_credentials grant type (see Web Authorization ) | |
| Parameter name | Description |
client_id | The OAuth Client ID for your application. |
client_secret | The 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:
| Response | Description |
|---|---|
access_token | The 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_in | The number of seconds until the token expires. |
expires_at | The expire date in ISO 8601 format. |
account_id | The Epic Account ID for the user that the token was generated for. |
client_id | The Client ID which was used to generate this token. |
application_id | The Application ID which the Client is associated with. |
token_type | The type of token generated; value will always be bearer. |
refresh_token | The 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_expires | The number of seconds until the refresh token expires. |
refresh_expires_at | The 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 https://api.epicgames.dev/epic/oauth/v1/.well-known/jwks.json
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 https://api.epicgames.dev/epic/oauth/v1/tokenInfo
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:
| Parameter | Description |
|---|---|
AUTH_LOGIN | Unused for exchange code. |
AUTH_PASSWORD | The credentials to be used by the game client. This will include the exchange code that will be passed to the authentication server. |
epicapp | Internal application name. |
epicenv | Environment that this is being launched in (always Prod). |
epicusername | Display name of the account that is authenticated in the Launcher. |
epicuserid | Epic Account ID for the account that is authenticated in the Launcher. |
epiclocale | Preferred locale based on user preference or based on the system language. |
epicovt | Full path to a file containing Ownership Verification Token information. |
epicsandboxid | The 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:
| Claim | Type | Description |
|---|---|---|
| iss | string | The base URI of the Epic Games authentication server that issued the token. |
| sub | string | This claim will not be present when using the client_credentials grant type. |
| aud | string | The client ID specified in the authorization request. |
| iat | integer | The time the token was issued as a UNIX timestamp. |
| exp | integer | Expiration time of the token as a UNIX timestamp. |
| jti | string | The unique identifier for this token. |
| t | string | The type of token. This should always be epic_id. This replaces the version prefix that we have with EG1 tokens. |
| scope | string | Space delimited list of scopes that were authorized by the user. |
| dn | string | The user's display name. |
| appid | string | The application ID specified in the authorization request. |
| pfpid | string | The product ID for the deployment that was specified in the token request. |
| pfsid | string | The sandbox ID for the deployment that was specified in the token request. |
| pfdid | string | The 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 https://api.epicgames.dev/epic/id/v1/accounts. 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: