This shows you the differences between two versions of the page.
| Both sides previous revisionPrevious revisionNext revision | Previous revision | ||
| network_stuff:sso [2022/12/20 21:02] – jotasandoku | network_stuff:sso [2024/12/19 22:08] (current) – jotasandoku | ||
|---|---|---|---|
| Line 1: | Line 1: | ||
| - | |||
| **SAML-SSO vs OAUTH-SSO**: | **SAML-SSO vs OAUTH-SSO**: | ||
| \\ | \\ | ||
| What is and Identity Provider [[https:// | What is and Identity Provider [[https:// | ||
| - | |||
| \\ | \\ | ||
| - | + | OpenID and SAML are associated with federated services, | |
| - | OAuth: | + | \\ |
| + | **OAuth**: | ||
| \\ | \\ | ||
| Line 15: | Line 14: | ||
| Google responds with the appropriate information, | Google responds with the appropriate information, | ||
| The SP then creates a local session associated with that information. In the case of Apache' | The SP then creates a local session associated with that information. In the case of Apache' | ||
| - | |||
| \\ | \\ | ||
| However this solution does not work for CompanyY because machines may wish to use SSO but not be allowed to connect directly to the IdP service, or indeed, may be physically unable to connect because the segment colour does not allow connections out, for example. So instead CompanyY uses SAMLv2 for SSO. | However this solution does not work for CompanyY because machines may wish to use SSO but not be allowed to connect directly to the IdP service, or indeed, may be physically unable to connect because the segment colour does not allow connections out, for example. So instead CompanyY uses SAMLv2 for SSO. | ||
| \\ | \\ | ||
| - | SAMLv2:\\ | + | **SAMLv2**: |
| + | \\ | ||
| SAMLv2 is similar to OAuth, except that all of the data is handled by the browser. Many of the steps are similar or approximately equivalent. | SAMLv2 is similar to OAuth, except that all of the data is handled by the browser. Many of the steps are similar or approximately equivalent. | ||
| Line 34: | Line 33: | ||
| + | |||
| + | SSO Using OAuth (OAuth 2.0) | ||
| + | |||
| + | User → SP: User tries to access a resource. | ||
| + | SP → IdP: SP redirects the user to the IdP (Authorization Endpoint). | ||
| + | IdP ↔ User: IdP authenticates the user. | ||
| + | IdP → SP: IdP provides an Authorization Code to the SP via the browser. | ||
| + | SP → IdP: SP exchanges the Authorization Code for an Access Token. | ||
| + | SP → Resource: SP uses the Access Token to grant the user access. | ||
| + | |||
| + | SSO Using SAML | ||
| + | |||
| + | User → SP: User attempts to log in or access the SP. | ||
| + | SP → IdP: SP redirects the user to the IdP with a SAML authentication request. | ||
| + | IdP ↔ User: IdP authenticates the user and generates a SAML assertion. | ||
| + | IdP → SP: The user submits the SAML assertion to the SP. | ||
| + | SP → Resource: SP validates the SAML assertion and grants access. | ||
| + | | ||
| + | | ||
| ---- | ---- | ||