Difference between revisions of "EVE SSO"
Line 34: | Line 34: | ||
# The Server creates an Authentication Token and Refresh Token and sends them to the Tool | # The Server creates an Authentication Token and Refresh Token and sends them to the Tool | ||
# If OAuth2 was used, some additional information about the character is included in JWK format (such as character name and character-id) | # If OAuth2 was used, some additional information about the character is included in JWK format (such as character name and character-id) | ||
+ | |||
The Authentication Token the Tool has now obtained is valid for 20 minutes. | The Authentication Token the Tool has now obtained is valid for 20 minutes. |
Revision as of 22:02, 18 December 2019
Single Sign On (SSO) is an OAuth/OAuth2-based Login service provided by CCPGames for EVE Online. This service permits third part applications and websites to authenticate players using their EVE Online credentials, thus proving their ownership of the character(s) they are logging in to.
OAuth and OAuth2
There are two "flavors" of OAuth: the original OAuth, sometimes called OAuth1 or OAuth v1, and the newer OAuth2. For the purposes of this article, they will be collectively referred to as OAuth, as the differences between them primarily affect the developer rather than the end-user (with the exception of a small increase in security in OAuth2).
OAuth is a web-standard shared login procedure that is well-established and tested. The nature of the login process means that the username and password are never shared with the destination website, so users can rest assured that their account cannot be "hacked" or any additional information beyond what they authorized the third party tool to use. The OAuth server maintains control of all of the information and validation.
OAuth is very widely used, but rarely known to users by that name. Most major Social website services that allow their users to use their credentials for other websites and tools are based on OAuth. This includes Google, Facebook and Twitter, among numerous others.
Authentication Process
When a user wishes to authenticate with a website or application (this article will refer to both as a "tool") that uses OAuth authentication, it triggers a multi-step process between all three parties: The user (typically via their browser), the tool (which serves as the OAuth client), and the OAuth server (which hosts the user's actual account).
- The User initiates a request to log in via OAuth/SSO to the Tool
- The Tool Redirects the User to the OAuth Server, with added information:
- a client-id that identifies the Tool to the Server (provided by server when the Tool registered previously)
- a redirect url that the Server will redirect the User to once they are signed in
- any Scopes the Tool is requesting access to for the User's information
- a 'state' parameter that helps the Tool identify the User when they return to the Tool, and also acts as an additional safety check
- The Server validates the client-id and the redirect url of the Tool against the registered information in its own database
- If the info is correct, the Server presents a login prompt to the User, along with the list of Scopes requested.
- The User logs in to their account and agrees to the scopes
- The Server redirects the User to the redirect URL of the Tool, and passes along information in the Header of the request that includes a Temporary Token
Up to this point, all of the data sent back and forth has been visible to the user in the URL parameters; both in the URL that sent them to the login screen and the return to the Tool. This is considered insecure as it could easily be "hacked" or subject to a "man in the middle" attack. Because of this risk, the Tool does not yet have full authentication with the Server. In the case of EVE SSO, the Temporary Token provided is only valid for 5 minutes. To get a full Authentication token, the Tool must follow these steps behind the scenes, invisible to the user:
- The Tool constructs a request to the Server with the following information:
- Client-ID
- Client-Secret
- Temporary Token
- The Server validates the Client-ID and Client-Secret against the registered client in the database
- The Server creates an Authentication Token and Refresh Token and sends them to the Tool
- If OAuth2 was used, some additional information about the character is included in JWK format (such as character name and character-id)
The Authentication Token the Tool has now obtained is valid for 20 minutes.
The Refresh Token the Tool has obtained is valid indefinitely, but can be invalidated in several manners:
- The User revokes it on their EVE Thrid Party Tools Authorization page -- https://community.eveonline.com/support/third-party-applications/
- The User changes their account password, which invalidates ALL Tokens on the account
- The User sells the Character on the Character Bazaar
- The Tool revokes it using the individual Token Revocation process
- The Tool developer deletes the tool's registration on the EVE Servers at https://developers.eveonline.com/
- The Tool developer changes the tool's registration on the EVE Servers in a manner that changes the client-id or client-secret
- Note: Changing the redirect URL does NOT affect Tokens issued.