OAuth 2.0 Concepts: Difference between revisions
No edit summary |
No edit summary |
||
| Line 9: | Line 9: | ||
Single Sign-On (SSO) systems allow a single user authentication process across multiple IT systems and organizations. SSO is a subset of federated identity management, as it relates only to ''authentication'' and technical interoperability. | Single Sign-On (SSO) systems allow a single user authentication process across multiple IT systems and organizations. SSO is a subset of federated identity management, as it relates only to ''authentication'' and technical interoperability. | ||
User's presence in the system - means that the user identity is associated with the thread that is processing the user's request, and in a way, it is the user that "drives" the thread. The identity is associated with the thread in the form of a ''security context''. | ''User's presence'' in the system - means that the user identity is associated with the thread that is processing the user's request, and in a way, it is the user that "drives" the thread. The identity is associated with the thread in the form of a ''security context''. | ||
There are software agents that perform actions ''on behalf'' of the user, and this is where OAuth is relevant - a user can delegate in a standard and secure way the authority of performing certain actions. Even the software agent (the ''OAuth client'') operates under a different identity, it can still perform action on behalf of a user that may not be even logged in anymore. An example of such identity is an [[OpenShift_Security_Concepts#Service_Account|OpenShift service account]]. | There are software agents that perform actions ''on behalf'' of the user, and this is where OAuth is relevant - a user can delegate in a standard and secure way the authority of performing certain actions. Even the software agent (the ''OAuth client'') operates under a different identity, it can still perform action on behalf of a user that may not be even logged in anymore. An example of such identity is an [[OpenShift_Security_Concepts#Service_Account|OpenShift service account]]. | ||
Authentication. | Authentication. The whole point of an authentication protocol is to tell whether the user ''is present'' in the system. | ||
Authentication protocols, single sign-on, SAML. | Authentication protocols, single sign-on, SAML. | ||
Authorization. | Authorization. | ||
Revision as of 20:17, 12 November 2017
Internal
Identity. Identity Management.
Identity Federation and Single Sign-On are related concepts.
Single Sign-On (SSO) systems allow a single user authentication process across multiple IT systems and organizations. SSO is a subset of federated identity management, as it relates only to authentication and technical interoperability.
User's presence in the system - means that the user identity is associated with the thread that is processing the user's request, and in a way, it is the user that "drives" the thread. The identity is associated with the thread in the form of a security context.
There are software agents that perform actions on behalf of the user, and this is where OAuth is relevant - a user can delegate in a standard and secure way the authority of performing certain actions. Even the software agent (the OAuth client) operates under a different identity, it can still perform action on behalf of a user that may not be even logged in anymore. An example of such identity is an OpenShift service account.
Authentication. The whole point of an authentication protocol is to tell whether the user is present in the system.
Authentication protocols, single sign-on, SAML.
Authorization.