m Authentication, Authorization: OAuth2, OpenId
- Jim Mason (Unlicensed)
- jimm1
- jim mason
Key Points
- OpenId is an authentication only solution
- OpenId is authentication only, can use OAuth2 for authorization
- OpenId Connect is current version
- Openid Connect ( OIDC ) can interface with DIDs for authentication
- OAuth2 implementations provide both authentication and authorization
- OAuth2 can grant more authority to an application than needed to authenticate an identity
- Pure identity providers only authenticate an identity to a client application for a purpose based on a request from a principal ( an entity or user )
References
Key Concepts
OpenID and OAuth2 use cases
OpenID for authentication
OAuth2 for delegated authorization
OAuth2
https://en.wikipedia.org/wiki/OAuth
OAuth can be used as an authorizing mechanism to consume secured RSS/ATOM feeds. Consumption of RSS/ATOM feeds that require authentication has always been an issue. For example, an RSS feed from a secured Google Site could not have been consumed using Google Reader. Instead, three-legged OAuth would have been used to authorize that RSS client to access the feed from the Google Site. It can also be used as a means to login without creating an account on any site and all the benefits of the host of the OAuth system.
OpenID
OpenID is for authentication only
OpenID with OAuth Delegated Resource Access
OpenID vs. pseudo-authentication using OAuth
OAuth is an authorization protocol, rather than an authentication protocol. Using OAuth on its own as an authentication method may be referred to as pseudo-authentication.[citation needed] The following diagrams highlight the differences between using OpenID (specifically designed as an authentication protocol) and OAuth for authentication.
The communication flow in both processes is similar:
- (Not pictured) The user requests a resource or site login from the application.
- The site sees that the user is not authenticated. It formulates a request for the identity provider, encodes it, and sends it to the user as part of a redirect URL.
- The user's browser requests the redirect URL for the identity provider, including the application's request
- If necessary, the identity provider authenticates the user (perhaps by asking them for their username and password)
- Once the identity provider is satisfied that the user is sufficiently authenticated, it processes the application's request, formulates a response, and sends that back to the user along with a redirect URL back to the application.
- The user's browser requests the redirect URL that goes back to the application, including the identity provider's response
- The application decodes the identity provider's response, and carries on accordingly.
- (OAuth only) The response includes an access token which the application can use to gain direct access to the identity provider's services on the user's behalf.
The crucial difference is that in the OpenID authentication use case, the response from the identity provider is an assertion of identity; while in the OAuth authorization use case, the identity provider is also an API p
OpenId vs OAuth2 - comparison flows for authentication
https://en.wikipedia.org/wiki/OAuth#/media/File:OpenIDvs.Pseudo-AuthenticationusingOAuth.svg
Compare OAuth2 and OIDC
compare oauth2 and oidc - 2022 **
OAuth_and_OpenID_Connect_in_plain_English_v1.6__KCDC_.pdf file
Authentication and Authorizing for WebService/REST API Calls
https://dzone.com/articles/authentication-and-authorizing-for-webservice-rest?edition=596291
Potential Value Opportunities
OpenId for Authentication
https://en.wikipedia.org/wiki/OpenID
OpenID is an open standard and decentralized authentication protocol.
Promoted by the non-profit OpenID Foundation, it allows users to be authenticated by co-operating sites (known as relying parties, or RP) using a third-party service, eliminating the need for webmasters to provide their own ad hoc login systems, and allowing users to log into multiple unrelated websites without having to have a separate identity and password for each.[1]
Users create accounts by selecting an OpenID identity provider, and then use those accounts to sign onto any website that accepts OpenID authentication. Several large organizations either issue or accept OpenIDs on their websites according to the OpenID Foundation.[2]
The OpenID standard provides a framework for the communication that must take place between the identity provider and the OpenID acceptor (the "relying party").[3] An extension to the standard (the OpenID Attribute Exchange) facilitates the transfer of user attributes, such as name and gender, from the OpenID identity provider to the relying party (each relying party may request a different set of attributes, depending on its requirements).[4]
The OpenID protocol does not rely on a central authority to authenticate a user's identity. Moreover, neither services nor the OpenID standard may mandate a specific means by which to authenticate users, allowing for approaches ranging from the common (such as passwords) to the novel (such as smart cards or biometrics).
The term OpenID may also refer to an identifier as specified in the OpenID standard; these identifiers take the form of a unique Uniform Resource Identifier (URI), and are managed by some "OpenID provider" that handles authentication.[1]
Web Authorization Protocol provides an authorization model for a principal to access an application service
http://www.potaroo.net/ietf/html/ids-wg-oauth.html
OAuth2 for Authorized Resource Access
OAuth2 use cases
OAuth2 Delegated Authorization Resource Access Flow
OAuth2 Steps
| OAuth 2.0 Proof-of-Possession: Authorization Server to Client Key Distribution | |||||||||||||||||
| RFC 6750 specified the bearer token concept for securing access to protected resources. Bearer tokens need to be protected in transit as well as at rest. When a client requests access to a protected resource it hands-over the bearer token to the resource server. The OAuth 2.0 Proof-of-Possession security concept extends bearer token security and requires the client to demonstrate possession of a key when accessing a protected resource. | ||||||||||||||||
| OAuth 2.0 Token Exchange | |||||||||||||||||
| This specification defines a protocol for an HTTP- and JSON- based Security Token Service (STS) by defining how to request and obtain security tokens from OAuth 2.0 authorization servers, including security tokens employing impersonation and delegation. | ||||||||||||||||
| The OAuth 2.0 Authorization Framework: JWT Secured Authorization Request (JAR) | |||||||||||||||||
| The authorization request in OAuth 2.0 described in RFC 6749 utilizes query parameter serialization, which means that Authorization Request parameters are encoded in the URI of the request and sent through user agents such as web browsers. While it is easy to implement, it means that (a) the communication through the user agents are not integrity protected and thus the parameters can be tainted, and (b) the source of the communication is not authenticated. Because of these weaknesses, several attacks to the protocol have now been put forward. This document introduces the ability to send request parameters in a JSON Web Token (JWT) instead, which allows the request to be signed with JSON Web Signature (JWS) and encrypted with JSON Web Encryption (JWE) so that the integrity, source authentication and confidentiality property of the Authorization Request is attained. The request can be sent by value or by reference. | ||||||||||||||||
| OAuth 2.0 Device Authorization Grant | |||||||||||||||||
| The OAuth 2.0 Device Authorization Grant is designed for internet- connected devices that either lack a browser to perform a user-agent based authorization, or are input-constrained to the extent that requiring the user to input text in order to authenticate during the authorization flow is impractical. It enables OAuth clients on such devices (like smart TVs, media consoles, digital picture frames, and printers) to obtain user authorization to access protected resources without using an on-device user-agent. | ||||||||||||||||
| OAuth 2.0 Security Best Current Practice | |||||||||||||||||
| This document describes best current security practice for OAuth 2.0. It updates and extends the OAuth 2.0 Security Threat Model to incorporate practical experiences gathered since OAuth 2.0 was published and covers new threats relevant due to the broader application of OAuth 2.0. | ||||||||||||||||
| OAuth 2.0 Mutual TLS Client Authentication and Certificate-Bound Access Tokens | |||||||||||||||||
| This document describes OAuth client authentication and certificate- bound access and refresh tokens using mutual Transport Layer Security (TLS) authentication with X.509 certificates. OAuth clients are provided a mechanism for authentication to the authorization server using mutual TLS, based on either self-signed certificates or public key infrastructure (PKI). OAuth authorization servers are provided a mechanism for binding access tokens to a client's mutual TLS certificate, and OAuth protected resources are provided a method for ensuring that such an access token presented to it was issued to the client presenting the token. | ||||||||||||||||
| JSON Web Token Best Current Practices | |||||||||||||||||
| JSON Web Tokens, also known as JWTs, are URL-safe JSON-based security tokens that contain a set of claims that can be signed and/or encrypted. JWTs are being widely used and deployed as a simple security token format in numerous protocols and applications, both in the area of digital identity, and in other application areas. The goal of this Best Current Practices document is to provide actionable guidance leading to secure implementation and deployment of JWTs. | ||||||||||||||||
| Resource Indicators for OAuth 2.0 | |||||||||||||||||
| An extension to the OAuth 2.0 Authorization Framework defining request parameters that enable a client to explicitly signal to an authorization server about the identity of the protected resource(s) to which it is requesting access. | ||||||||||||||||
| JWT Response for OAuth Token Introspection | |||||||||||||||||
| This draft proposes an additional JSON Web Token (JWT) based response for OAuth 2.0 Token Introspection. | ||||||||||||||||
| OAuth 2.0 for Browser-Based Apps | |||||||||||||||||
| OAuth 2.0 authorization requests from browser-based apps must be made using the authorization code grant with the PKCE extension, and should not be issued a client secret when registered. This specification details the security considerations that must be taken into account when developing browser-based applications, as well as best practices for how they can securely implement OAuth 2.0. | ||||||||||||||||
| JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens | |||||||||||||||||
| This specification defines a profile for issuing OAuth2 access tokens in JSON web token (JWT) format. Authorization servers and resource servers from different vendors can leverage this profile to issue and consume access tokens in interoperable manner. | ||||||||||||||||
Potential Challenges
Candidate Solutions
FIDO - all passwords replace by passkey from phone
https://blog.google/technology/safety-security/one-step-closer-to-a-passwordless-future/
https://www.theverge.com/2022/5/5/23057646/apple-google-microsoft-passwordless-sign-in-fido
https://fidoalliance.org/what-is-fido/
the problem with passwords and impacts
FIDO
Based on free and open standards from the FIDO Alliance, FIDO Authentication enables password-only logins to be replaced with secure and fast login experiences across websites and apps
supported by Microsoft, Google, Apple
where is AWS?
combine FIDO passkey with MFA for secure access ?? ( theory, reality is if everything on phone there's a SPOF )
Step-by-step guide for Example
sample code block