OAuth: open-standard authorization protocol adds the ability to your application to
use secure designated access.
SAML: Security Assertion Markup Language, SAML enables enterprises to monitor who
has access to corporate resources.
OAuth is an authorization process not an authentication process. There is a difference
between authorization and authentication. Authentication verifies the identity of a user
or service, and authorization determines their access rights. So using only OAuth will be
like your system will remain a system where no authentication process is enabled. And
this is not a very good security practice as my idea of cybersecurity.
OAuth tokens no longer need to be encrypted on the endpoints in 2.0 since they are
encrypted in transit.
OAuth 2.0 is meant to have a clean separation of roles between the server responsible
for handling OAuth requests and the server handling user authorization.
OAuth is actually a process of authorizing a user from a trusted third party that you
believe.
The main flow of OAuth: Instead of using the resource owner's credentials to access
protected resources, the client obtains an access token -- a string denoting a specific
scope, lifetime, and other access attributes. Access tokens are issued to third-party
clients by an authorization server with the approval of the resource owner. The client
uses the access token to access the protected resources hosted by the resource server.
Roles of OAuth:
resource owner
An entity capable of granting access to a protected resource.
When the resource owner is a person, it is referred to as an
end-user.
resource server
The server hosting the protected resources, capable of accepting
and responding to protected resource requests using access tokens.
client
An application making protected resource requests on behalf of the
resource owner and with its authorization. The term "client" does
not imply any particular implementation characteristics (e.g.,
whether the application executes on a server, a desktop, or other devices).
authorization server
The server issuing access tokens to the client after successfully
authenticating the resource owner and obtaining authorization.
Protocol Flow
OAuth grants 4 types:
1. Authorization code
2. Implicit
3. Resource Owner Password Credentials
4. Client Credentials
OpenID Connect (OIDC):
OpenID Connect (OIDC) is an open authentication protocol that works on top of the
OAuth 2.0 framework. OIDC allows individuals to use single sign-on (SSO).
JSON Web Token (JWT):
Contains 1. Header
2. Payload
3. Signature
OAuth Threat model: Two of the three parties involved in the
(follow this link)
OAuth protocol may collude to mount an attack against the 3rd party. For example, the
client and authorization server may be under the control of an attacker and collude to
trick a user to gain access to resources.
Vulnerability in Authorization Endpoint: Threat: Password Phishing by Counterfeit
Authorization Server OAuth makes no attempt to verify the authenticity of the
authorization server. A hostile party could take advantage of this by intercepting the
client's requests and returning misleading or otherwise incorrect responses. This could
be achieved using DNS or Address Resolution Protocol (ARP) spoofing. Wide
deployment of OAuth and similar protocols may cause users to become inured to the
practice of being redirected to websites where they are asked to enter their passwords.
If users are not careful to verify the authenticity of these websites before entering their
credentials, it will be possible for attackers to exploit this practice to steal users'
passwords.
Obtaining Access Tokens from Authorization Server Database
Let get the process of protecting of OAuth flow
1. Protecting Redirect-Based Flows: Validate the redirect url to avoid malicious
party redirection.
2. Token Replay Prevention: Mutual TLS for OAuth 2.0
3. Client Authentication: Authorization servers SHOULD use client authentication
if possible.
4. Refresh token: refresh token should be rotated always.
What Is Certificate Pinning?
: Certificate pinning is an online application security technique, originally devised as a means of
thwarting man-in-the-middle attacks (MITM), that accepts only authorized (“pinned”) certificates
for authentication of client-server connections. Any attempted secure connection requests
utilizing certificates other than those that are pinned are refused. Applications most commonly
pin an X.509 certificate, such as secure sockets layer (SSL) and transport layer security (TLS)
protocols that are the foundation of HTTPS secure browser connections, though just a trusted
Certificate Authority (CA) or public key can also be pinned.
–>>Certificate pining have more risk than it’s rewords.
