Difference between revisions of "User:Rayanth/Sandbox2"
(Fleet-up rework was performed by Edhin.) |
|||
| Line 1: | Line 1: | ||
| + | ESI and SSO | ||
| + | ===For Non-Developers=== | ||
| + | Safety: Your SSO username and password are completely safe from the third party application you're logging in to. When logging in to another service with SSO, you are actually logging on to the SSO server via a website hosted by CCP themselves. This setup is the core of an authentication method called OAuth (and its newer version, OAuth2). OAuth/OAuth2 are very widely used today, and act as the core component for logs on most social media giants, including Facebook, Twitter, and Google, including any other site that allows you to use those Social Media accounts to log in to them. | ||
| + | Here is a brief tour of the process, for a new 3rd party Eve Online tool, 3rd Party Website (3PW for short): | ||
| + | * 3PW registers its existence on CCP's servers. It defines a Redirect URL that will be listening for SSO to talk to it when a user logs in. | ||
| + | * 3PW receives a Client ID that it can identify itself with, and a Secret Key that lets it prove it is who it says it is, to SSO's servers. | ||
| + | * User decides to log in to 3PW | ||
| + | * 3PW redirects user to CCP-hosted SSO service. In the background, 3PW passes SSO its Client ID, Secret Key, Redirect URL, and a list of Scopes it would like access to. | ||
| + | * SSO verifies that 3PW's Client ID and Secret Key match, and to be sure they weren't hijacked, ensures the Redirect URL matches the one on record. | ||
| + | * User logs in to SSO as normal | ||
| + | * SSO presents User with the requested Scopes to verify they are willing to grant them | ||
| + | * User accepts the scopes | ||
| + | * SSO generates a short-duration (5 minutes) token and redirects the User to 3PW's Redirect URL, attaching the token to the URL. | ||
| + | * 3PW reads the token, and sends it back to SSO behind the scenes, to request a proper Authentication Token that lasts 20 minutes, and a Refresh token that lasts indefinitely. (The refresh token allows 3PW to refresh the Authentication token without making the user log in again) | ||
| + | * 3PW now can use the Authentication Token to request information from ESI that User granted it, via the requested Scopes. | ||
| + | |||
| + | The important thing to take away from this is that the above exchange ensures that each of the three parties can trust the other two: | ||
| + | |||
| + | * 3PW trusts the User because SSO authenticated them | ||
| + | * 3PW trusts SSO because | ||
| + | * SSO trusts 3PW because it verified the Client ID, Secret Key, and Redirect URL | ||
| + | * SSO trusts User because the user used their credentials (including 2FA if enabled) | ||
| + | * User trusts SSO because they have an existing with SSO | ||
| + | * User implicitly trusts 3PW because SSO verified 3PW's credentials. | ||
| + | |||
| + | ===Scopes=== | ||
| + | There are currently a total of 68 different scopes that can be requested/given to an application via ESI and SSO. These scopes control access to 126 of the 206 ESI endpoints (the remaining 80 are public and require no scopes). Some are only available to members of a corporation who have been granted particular titles/roles within the corporation. The following tables will help identify exactly what a granted scope permits access to. | ||
| + | |||
| + | <code>publicData</code>: This scope does not provide the 3rd party app with any information that is not publicly available. Its primary use is to give a Refresh token for the user's credentials, where otherwise no scope is requested. | ||
| + | |||
| + | Character-Focused scopes: | ||
Revision as of 18:40, 21 July 2019
ESI and SSO
For Non-Developers
Safety: Your SSO username and password are completely safe from the third party application you're logging in to. When logging in to another service with SSO, you are actually logging on to the SSO server via a website hosted by CCP themselves. This setup is the core of an authentication method called OAuth (and its newer version, OAuth2). OAuth/OAuth2 are very widely used today, and act as the core component for logs on most social media giants, including Facebook, Twitter, and Google, including any other site that allows you to use those Social Media accounts to log in to them. Here is a brief tour of the process, for a new 3rd party Eve Online tool, 3rd Party Website (3PW for short):
- 3PW registers its existence on CCP's servers. It defines a Redirect URL that will be listening for SSO to talk to it when a user logs in.
- 3PW receives a Client ID that it can identify itself with, and a Secret Key that lets it prove it is who it says it is, to SSO's servers.
- User decides to log in to 3PW
- 3PW redirects user to CCP-hosted SSO service. In the background, 3PW passes SSO its Client ID, Secret Key, Redirect URL, and a list of Scopes it would like access to.
- SSO verifies that 3PW's Client ID and Secret Key match, and to be sure they weren't hijacked, ensures the Redirect URL matches the one on record.
- User logs in to SSO as normal
- SSO presents User with the requested Scopes to verify they are willing to grant them
- User accepts the scopes
- SSO generates a short-duration (5 minutes) token and redirects the User to 3PW's Redirect URL, attaching the token to the URL.
- 3PW reads the token, and sends it back to SSO behind the scenes, to request a proper Authentication Token that lasts 20 minutes, and a Refresh token that lasts indefinitely. (The refresh token allows 3PW to refresh the Authentication token without making the user log in again)
- 3PW now can use the Authentication Token to request information from ESI that User granted it, via the requested Scopes.
The important thing to take away from this is that the above exchange ensures that each of the three parties can trust the other two:
- 3PW trusts the User because SSO authenticated them
- 3PW trusts SSO because
- SSO trusts 3PW because it verified the Client ID, Secret Key, and Redirect URL
- SSO trusts User because the user used their credentials (including 2FA if enabled)
- User trusts SSO because they have an existing with SSO
- User implicitly trusts 3PW because SSO verified 3PW's credentials.
Scopes
There are currently a total of 68 different scopes that can be requested/given to an application via ESI and SSO. These scopes control access to 126 of the 206 ESI endpoints (the remaining 80 are public and require no scopes). Some are only available to members of a corporation who have been granted particular titles/roles within the corporation. The following tables will help identify exactly what a granted scope permits access to.
publicData: This scope does not provide the 3rd party app with any information that is not publicly available. Its primary use is to give a Refresh token for the user's credentials, where otherwise no scope is requested.
Character-Focused scopes:
