Authentication and Authorization- Mechanisms

Authentication and authorization mechanisms are essential components of any secure system, ensuring that users and systems are who they claim to be and that access to resources is granted appropriately. This page provides a detailed overview of the most effective mechanisms for implementing robust authentication and authorization in modern applications, empowering developers and security professionals to protect their systems and data.

HTTP Basic Authentication

HTTP basic authentication is a simple authentication mechanism in which a server requests authentication information (a user ID and password) from a web browser client.

The client passes the authentication information to the server in an Authorization header. The authentication information is in base-64 encoding.
If a client makes a request for a protected resource, the server sends an HTTP response with a 401 status code, a reason phrase indicating an authentication error, and a WWW-Authenticate header. Most web clients handle this response by requesting a user ID and password from the user.
The format of a WWW-Authenticate header for HTTP basic authentication is:

WWW-Authenticate: Basic realm=”Secure Website”

The WWW-Authenticate header contains a realm attribute, which identifies the set of resources to which the user ID and password will apply.
When the web client has obtained a user ID and password, it resends the original request with an Authorization header. Alternatively, the client can send the Authorization header when it makes its original request, and this header might be accepted by the server, avoiding the challenge and response process.

The format of the HTTP Authorization header is:

Authorization: Basic <Base64 encoding of <userid:password>>

Eg: Authorization: Basic dHdpbGlvOmFob3kh

Password Based Login

Password-based login is the regular login authentication method that you will use the most frequently when using an online service. When utilizing the Password-Based Authentication method, you must provide both your username/mobile number and a password. Only once both of these criteria have been established is the person given permission.

Users find password-based authentication to be simple: they just input the necessary information to get access to a website or service.

Advantages of password based authentication

Organizations and end users alike can benefit from password-based authentication, including:

1. Familiarity: Passwords are the most often used authentication mechanism since they are known to users, which makes for a better user experience and less support calls.
2. Affordability: Password-based authentication is very easy and affordable while yet providing a minimum degree of security, unlike some other authentication techniques that call for more complex technologies or additional hardware and software. Because of this, small enterprises with less resources tend to favor it (although this tendency is changing).
3. User control: Password-based authentication allows users to alter or reset their passwords whenever they choose. Users now have the freedom to handle their passwords however they see suitable.

Disadvantages of password based authentication

Although password-based authentication methods have certain benefits, they are far from perfect. Other drawbacks include: Having to write down, remember, or utilize a password manager to store the hundreds of sets of credentials the typical individual currently possesses.

1. Vulnerability: One of the main dangers of password-based authentication is the ease with which passwords may be stolen or guessed, especially if they are weak or frequently used across different platforms. Additionally, if a user’s password is stolen, a hacker might access their account and possibly sensitive data.
2. Easy predictability: Individuals frequently use weak passwords. In fact, according to some estimates, close to 60% of people use their own name or birthday. Furthermore, barely a third of users don’t reuse passwords on other platforms. In order to guess or steal users’ credentials, brute force attacks like credential stuffing take use of inherent human predictability.
3. Fallibility: Passwords can be forgotten. Computers that have credentials saved crash. Even hard copies of information might disappear or be taken. Although users may usually change their passwords by email, if their primary email is stolen or closed, they risk losing access to their accounts permanently.
4. Complexity: Although password-based authentication is straightforward, it may become complicated if users are forced to generate complex passwords that adhere to strict specifications like minimum length, special characters, and numerals. Users may become irritated by this and be more inclined to give up, which can reduce conversion rates. The time that could be spent on other business-critical objectives by IT and help desk personnel is consumed by password reset procedures.

Multi-Factor Authentication (MFA)

A factor in user authentication is a way of confirming your identity when you try to sign in. For example, a password is one kind of factor, it’s a thing you know.

The three most common kinds of factors are:

• Something you know – Like a password, or a memorized PIN.
• Something you have – Like a smartphone, or a secure USB key.
• Something you are – Like a fingerprint, or facial recognition.

Multifactor Authentication (MFA) is a security mechanism that verifies a user’s identity for a login or other transaction by requiring several factors of authentication from separate categories of credentials. Multifactor authentication combines two or more separate forms of identification: what the person is (through biometric verification techniques) and what they have (such as a security token or password).

By utilizing several authentication levels, the user account will remain safe even if one piece is broken or deactivated. That’s the catch, though!

Advantages

1. Using MFA, application can send OTPs to phones that are randomly generated in real time and is difficult for hackers to break.
2. MFA can reduce data security breaches by up to 99.9% over passwords alone.
3. MFA adds additional layers of security at the hardware, software and personal ID levels
4. MFA can be easily set up by users.

Disadvantages

1. To setup MFA, a phone is needed to get a text message code.
2. Hardware tokens can get lost or stolen
3. Users phones can get lost or stolen
4. MFA verification can fail if there is a network or internet outage; and
5. MFA techniques must constantly be upgraded to protect against criminals who work incessantly to break them

Biometric Authentication

Biometric authentication is a security process that depends on the unique biological traits of individuals to verify they are who they say they are. Biometric authentication systems match recorded, verified, valid data in a database with physical characteristics or behavioral patterns. Authentication is validated if the biometric data from the two samples agrees.

This process is used to control access to physical and digital resources, such as buildings, rooms, and different devices.

The important thing to note is that the match between the two data sets has to be nearly identical but not exactly identical.

Various biometric authentication methods

1. Visual such as Retina scans, Iris recognition, Fingerprint scan, Facial recognition etc.
2. Vascular by means of vein patterns in the finger
3. Behavioral via typing speed and pattern of walking
4. Voice Id via frequency and tone of their voice

Advantages:

1. Convenient and secure
2. Difficult to replicate

Disadvantages:

1. Biometric Data theft
2. Privacy concerns

Certificate-based authentication

Certificate-based authentication (CBA) makes uses of a cryptographic digital certificate to identify a user, device or machine, before granting access to an application, network or other resources.

Certificate-based authentication can be used for all endpoints, including servers, personal computers, e-passports, and essentially anything that may be categorized as an Internet of Things (IoT) device, in contrast to other authentication solutions that are targeted at humans, such as one time passwords (OTP) and biometrics.

CBA is a far more secure alternative than the conventional username and password combination, although it may also be used in combination with traditional methods for the purposes of strong user authentication, creating a form of phishing-resistant MFA. As the digital certificate of a subject resides on an individual’s device along with the private key, it enables the user’s browser or application client to log into various systems automatically without much additional effort from the user, since it can simply be presented when requested.

Common use cases of a Certificate based login

User Authentication

1. Email access, internal networks or intranets
2. Windows login
3. Accessing cloud-based servers

Machine and device authentication

1. Identifying on-location/in-field machines that need to communicate with back-end services Identifying all employee laptops and mobile devices before allowing access to WiFi networks, VPNs, Gateways, etc.
2. Identifying all servers within the enterprise to enable mutual authentication

Mechanics of Certificate-Based Authentication

A subject’s digital identity certificate is an electronic document used to prove private key ownership. A digital identity certificate is an electronic document used to prove private key ownership. Certificate-based authentication uses the information within said document to verify the user, device or machine, in contrast to the classic username and password combination which is strictly limited to verifying only those who are in possession, i.e. potentially not just the user who should have access. The increased sophistication of attacks, coupled with the exploding number of attack surfaces as more and more devices access the network, make this additional capability more necessary than ever.

Depending on the standard being used, a digital certificate comprises a variety of significant details. For instance, the well-known X.509 certificate has the parts listed below:

• The public key
• The user or device’s name
• The name of the Certificate Authority (CA) that issued the certificate
• The date from which the certificate is valid
• The expiry date of the certificate
• The version number of the certificate data
• A serial number

Token-Based authentication

Subjects can confirm their identity using the token-based authentication system, and in exchange they get a special access token. Instead of having to reenter credentials each time they return to the same webpage, app, or other resource secured with the same token, users may access the website or app for which the token has been granted for the duration of the token.

Auth tokens function like a ticket with a stamp. As long as the token is active, the user has access. The token expires when the user logs out or closes an application.

The classic password-based or server-based authentication methods are distinct from token-based authentication. Administrators have precise control over each activity and transaction, and tokens provide an additional degree of protection.

When paired with the right tokenization technology, a token—a piece of data with no inherent meaning or utility—becomes an essential component of your application’s security. Each request to a server must be accompanied by a signed token, which the server then validates for validity before fulfilling the request. This is how token-based authentication functions.

JSON Web Token (JWT) is an open standard (RFC 7519) that defines a compact and self-contained method for securely transmitting information between parties encoded as a JSON object. JWT has gained mass popularity due to its compact size which allows tokens to be easily transmitted via query strings, header attributes and within the body of a POST request.

Benefits of tokens compared to traditional cookies:

Tokens are stateless. The token is self-contained and contains all the information it needs for authentication. This is great for scalability as it frees your server from having to store session state.
Tokens can be generated from anywhere. Token generation is decoupled from token verification allowing you the option to handle the signing of tokens on a separate server or even through a different provider.
Fine-grained access control. Within the token payload you can easily specify user roles and permissions as well as resources that the user can access.

Passwordless Authentication

Without providing a password or responding to security questions, a user can access an application or IT system using passwordless authentication. The user instead offers another type of proof, such a fingerprint, proximity badge, or hardware token code. Passwordless authentication is frequently used with Multi-Factor Authentication (MFA) and Single Sign-On (SSO) technologies to enhance user experience, boost security, and simplify and lower the cost of IT operations.

Passwordless authentication improves security by getting rid of unsafe password management procedures and cutting down on attack points. By removing the weariness associated with passwords and secrets, it also enhances user experiences. There are no passwords or security question answers to memorize with passwordless authentication. Users can conveniently and securely access applications and services using other authentication methods such as:

• Fingerprint, voice or facial recognition, or retina scanning
• A mobile phone application
• Proximity badges, physical tokens, or USB devices (FIDO2-compliant keys)
• Software tokens or certificates

Advantages of Passwordless Authentication:

• Enhance User Experience- by removing the need for passwords and other security measures and by offering uniform access to all programs and services.
• Strengthen Security – by eliminating risky password management techniques and reducing credential theft and impersonation.
• Enhance IT processes – Eliminate the need to create, protect, rotate, reset, and maintain passwords to simplify IT processes.

API Authentication

In modern web & mobile applications, REST APIs have become a common architectural approach. They separate data and presentation layers, which enables systems to evolve in features over time.

Security becomes a major concern for REST APIs that hold sensitive information as data crosses borders, though. One of the most common ways to secure these APIs is to implement vbcnauthentication mechanisms that control their exposure, mainly through user credentials and encrypted access codes.

API authentication works through the presentation of a credential and/or supporting data end points, followed by its acceptance or rejection. The credential can be an API key, a username/password pair, or a digital token. Supporting data points can be information related to the user’s device or location.

Types of API authentication methods

HTTP Basic Authentication – The simplest API authentication method, HTTP Basic Authentication, just needs users to supply usernames and passwords encoded in Base64. Cookies and session IDs are absent. The technique makes advantage of the HTTP header and is quite easy to understand. Other options are not required.

API Key Authentication – API Key Authentication was developed to address HTTP Basic Authentication’s shortcomings as a method of authentication due to the vulnerability of shared credentials. When using API key authentication, the server verifies the API key’s authenticity, at this point it confirms the user’s identity and grants him access to the API. A “bearer token” is another name for the API key.

OAuth Authentication — When it comes to REST API authentication, OAuth (particularly, OAuth 2.0) is regarded as the gold standard, especially in business settings requiring complex online and mobile apps. Dynamic collections of users, permission levels, scope parameters, and data kinds are supported by OAuth 2.0. For businesses wishing to protect several REST APIs that handle sensitive data, this method is ideal.

OAuth 2.0 generates a secured access tokens that are refreshed periodically using a series of procedural verification protocols known as grant types. These grant types function as a proxy authentication mechanisms that direct the flow of API access requests without exposing the underlying credentials, tokens and other authentication information associated with those requests.

FIDO Security key

Fast Identity Online (FIDO) is a technical specification for online user identity authentication. It is used in scenarios such as fingerprint login and two-factor login, allowing you to use biological features or a FIDO security key to log in to your online accounts. Since it improves security, protects privacy, and simplifies the verification experience, devices such as windows computers and popular phones support this feature.

Standard public key cryptography methods are used by the FIDO protocols to enable enhanced authentication. A fresh key pair is generated by the user’s client device after registration with an online service. The public key is registered with the internet service, and the private key is kept. The client device authenticates itself by signing a challenge to demonstrate ownership of the service’s private key. Only until the user unlocks the client’s private keys locally on the device can they be utilized. A user-friendly and secure action, such as swiping a finger, entering a PIN, speaking into a microphone, inserting a second-factor device, or pressing a button, is used to unlock the local device.

The privacy of users is protected by the FIDO protocols from the bottom up. The protocols don’t include data that multiple internet services can use to communicate and follow a user between services. If utilized, biometric data never leaves the user’s device.

Passkeys

Passkeys, which are based on FIDO standards, allow for quicker, simpler, and more secure sign-in to websites and apps across a user’s devices. Unlike passwords, passkeys are always strong and phishing-resistant.

A passkey is a digital credential, bind to a user account and a website or application. Passkeys allow users to authenticate without having to enter a username or password, or provide any additional authentication factor. This technology attempts to take the place of antiquated authentication methods like passwords.

A user’s browser or operating system will assist them in choosing and using the appropriate passkey when they wish to sign in to a service that accepts passkeys. The procedure is comparable to how today’s stored passwords operate. The system will prompt the user to unlock their device to ensure that only the rightful owner may use a passkey. This might be done via a pattern, PIN, or biometric sensor (such a fingerprint or face recognition).

A passkey can meet multifactor authentication requirements in a single step, replacing both a password and OTP (e.g. 6-digit SMS code) to deliver robust protection against phishing attacks and avoids the UX pain of SMS or app-based one-time passwords.

Since passkeys are standardized, a single implementation enables a password less experience across all of a users’ devices, across different browsers and operating systems.

Addressing Security Concerns

• Passkeys use public key cryptography. Public key cryptography reduces the threat from potential data breaches. When a user creates a passkey with a site or application, this generates a public–private key pair on the user’s device. Only the public key is stored by the site, but this alone is useless to an attacker. An attacker can’t derive the user’s private key from the data stored on the server, which is required to complete authentication.

• Because passkeys are bound to a website or app’s identity, they’re safe from phishing attacks. The browser and operating system ensure that a passkey can only be used with the website or app that created them. This frees users from being responsible for signing in to the genuine website or app.

Magic Links

Magic links are a one-time use link sent to the user during the authentication process. After providing the username, the user is sent a URL, either to the user’s email address or their mobile phone via text. The user clicks to authenticate themselves without entering a password.

Magic links are appealing because they provide a quick solution to eliminate the requirement for a consumer to create and remember a password.

Scenarios where magic links are used

1. Rare instances where authentication is required: When a user just has to authenticate once at the start of the session, magic links function nicely. Complex password entry makes the task more difficult.
2. Where device authentication is already in place: Magic links can be a choice if device authentication is already being done. Situations in which a prompt and simple account creation is desired:
3. In situations where fast account creation is desired: Password-based authentication slows down the account creation process. With the need for ever stronger passwords due to the rapid increase in password-based attacks, you’ll need to force end-users to create complex passwords. Magic links make that unnecessary.

Security Concerns

Magic links are designed to streamline and secure the login process. However, each benefit that makes magic links appealing for passwordless authentication also poses serious security concerns:

There is no guarantee that the person who receives the magic link is who they claim to be.

Authenticator

An authenticator app is a mobile application that usually gets installed on a smartphone or mobile device. The app generates a six- to eight-digit security key in a specific time window, usually 30 seconds. These codes are usually generated by an algorithm.

Unlike SMS text message-based 2FA, you would open the authenticator application on your smartphone to retrieve a 6-digit code instead.

This is achieved after linking your authenticator app to your online account using your smartphone’s camera to scan a QR code and entering the 6-digit code displayed.

Cognitive Passwords

A password that requires the user to respond to a series of questions, either factual ones like “what is your mother’s maiden name?” or subjective ones like “what is your favorite kind of music?”

Form-based authentication

Form-based authentication enables you to create customized HTML Web forms that process user logins using the Access System’s authentication and authorization mechanisms.

The majority of Form-based authentication systems employ regular HTML form fields to send the server a POST request with the login and password values. With each http request, the client and server exchange a unique token saved in a cookie that is used to authenticate the specified credentials and establish a “session” between them. The server then often redirects to a login page if the cookie is incorrect or the user is logged out.

Mutual Authentication

In Mutual Authentication, the server and the client authenticate to one another during mutual authentication.

In a certificate based for mutual authentication, the following actions take place:

1. The client asks to access a restricted resource.
2. The web server shows the client its certificate.
3. The client checks the server’s certificate.
4. If all goes well, the client will deliver the server its certificate. The server checks client recommendations.
5. If all goes well, the server grants the client’s request for access to the protected resource.

Kerberos Authentication

Kerberos is a well-known authentication protocol that is used to verify the identity of a user or host.

Kerberos offers a reliable security solution for businesses of all sizes. To authenticate and confirm user identities, Kerberos utilizes symmetric key cryptography and a key distribution center (KDC).

Three components make up a KDC:

1. A ticket-granting server (TGS) which connects the user with the service server (SS)
2. A Kerberos database that stores the credentials of all verified users
3. An authentication server (AS) that performs the initial authentication

Advantages of Kerberos Authentication

1. Single Sign on
2. Mutual Authentication
3. Efficient authentication to servers
4. Security

Despite the fact that Kerberos has been around for a while, it is still in use today. Even if cyberattackers were able to break it, it is still a tried-and-true security access mechanism. The fact that Kerberos utilizes robust encryption to safeguard authentication tickets and passwords is one of its main benefits.

Digest Authentication

Another authentication mechanism mentioned in HTTP 1.1 is digest authentication. Digest authentication does not need the password to be communicated, in contrast to basic authentication. Instead, a hash created by the client using the login and password and the MD5 hashing technique is provided to the Server.

Digest access authentication is preferable over basic access authentication, which employs insecure Base64 encoding over HTTP. Basic access authentication is insecure unless used in conjunction with transport-layer security (TLS).

Digest Authentication workflow

1. Client makes request to a resource
2. Client gets back a nonce from the server and a HTTP Status code 401 authentication request
3. The client sends back the following response array (username, realm, calculate_md5_key(nonce, username, realm, URI, password_given_by_user_to_browser))
4. The server takes username and realm (plus it knows the URI the client is requesting) and it looks up the password for that username. Then it goes and generates its own value of calculate_md5_key (nonce, username, realm, URI, password_for_the_user_in_the_db)
5. It compares the output of calculate_md5_key function that it got with the one the client sent, if they match the client sent the correct password. If they don’t match the password provided was wrong.

Device Authentication

Device Authentication or Endpoint authentication is a security mechanism designed to ensure that only authorized devices can be connected to a given network, site or service.

Devices often considered can be a mobile computing device, like a laptop, smart phone or tablet but it could be any connected hardware device on a TCP/IP network. Potential items also include desktop computers, printers, servers and specialized hardware such as POS terminals, Smart meters and other smart devices.

Device/Endpoint security management is gaining importance in the developing areas of machine-to-machine (M2M) communications and the Internet of Things (IoT). Device/Endpoint fingerprinting is one method of enabling authentication of non-traditional network endpoints such as smartcard readers, HVAC systems, medical equipment and IP-enabled door locks.

Adaptive Authentication

The technique of authenticating a user based on the degree of risk that a login attempt presents is known as adaptive authentication. Its usage of multi-factor authentication is a crucial aspect. Usually, the initial authentication method automatically determines the risk level, and if the risk of fraud is minimal, the login is approved. Step-up authentication is activated and the user is prompted for a different kind of authentication if the risk is high.

Adaptive authentication intelligently selects how a user must authenticate based on various contextual elements. The fact that the elements are evaluated repeatedly rather than just once throughout the user session makes this authentication approach more secure and zero-trust.

Some of the parameters adaptive authentication should consider during authentication are:

Location Awareness: Where is the service request originating from, is this a “risky” IP address range, or this belongs to a “risky” country? How did the user get from Hong Kong to some other country in one hour? This isn’t the regular location from which this user is logging on.

Device Profile: What system/device is the request coming from? Is this a system/device accessed before, is this a corporate-issued device?

User Behavior: Why is the user accessing these servers/applications/data? He has never accessed before.

Why it is important?

Organizations these days are more flexible than ever in the way they handle and support employee technology use. Full-time remote or hybrid employment models allow team members to log in and work from a wide variety of locations, and bring-your-own-device (BYOD) policies enable the use of numerous kinds of endpoints.

This growth in adaptability is empowering organizations, in many cases allowing them to be productive from their teams. However, if they don’t include security upgrades, firms risk being attacked by IT attacks that are aimed at weak spots in networks and devices.

The digital ecosystems of today no longer support IT security that is one size fits all. Any rigid regulation will always be either too lenient or too rigorous when put into practice by today’s workforce. The solution to this problem is adaptive authentication, which makes sure that there is a balance between tight security and user comfort.

A good adaptive authentication solution provides various MFA options such as:

1. SMS Verification
2. Mobile push notification to registered device
3. Email Verification
4. Phone calls to users

RADIUS

Remote Authentication Dial-In User Service (RADIUS) is a client-server authentication protocol that was originally designed to authenticate remote users to a dial-in access server of Internet Service providers (ISPs).

Currently, it is used in a wide range of authentication scenarios.

A RADIUS Client (or Network Access Server) is a networking device (like a VPN concentrator, router switch etc.) that is used to authenticate users.

A RADIUS Server is a server process running on a UNIX or Windows server. It manages user profiles in a central database.

The precise working of the RADIUS environment affects how the RADIUS Server functions. However, AAA (Authentication, Authorization, and Accounting) capabilities are present on every server. A RADIUS Server may also function as a proxy client for other RADIUS Servers in some RADIUS ecosystems.

RADIUS authentication approaches

Password Authentication Protocol (PAP) – The user ID and password of the distant user are transmitted to the RADIUS authentication server by the RADIUS client. The RADIUS client allows the distant user to join to the network if the credentials are valid, and the server authenticates the user if they are.

Challenge Handshake Authentication Protocol (CHAP) – CHAP authentication, sometimes referred to as a three-way handshake, and depends on the client and server sharing an encrypted shared secret. Because it can be set up to do several mid-session authentications and encrypts authentication exchanges, CHAP authentication is thought to be more secure than PAP.

RADIUS protocol has various types of messages for various purposes.

A typical RADIUS authentication process includes the following steps:

1. A shared secret is shared and setup between the client and server by the administrator.
2. The RADIUS Client tries to authenticate to the RADIUS Server using user credentials.
3. Client sends an Access-Request message to the RADIUS Server. Passwords are always encrypted in the Access-Request message.
4. RADIUS Server responds with Accept, Reject, or Challenge.
5. The RADIUS Client acts upon services based on the parameters provided with Accept or Reject.

JWT

JSON web token (JWT), pronounced “jot”, is an open standard (RFC 7519) that offers a compact and self-contained method for securely sending information between parties as a JSON object.

Applications of JWTs

For Authentication – An ID token is returned when a user successfully signs in using their credentials. An ID token should always be a JWT, according to the OpenID Connect (OIDC) specifications.

For Authorization – After a user has successfully signed in, an application may request access to routes, services, or resources (e.g., APIs) on that user’s behalf. To do so, each request must include an Access Token, which might be in the form of a JWT. JWT is frequently used in Single Sign-on (SSO) because of its low overhead and flexibility to be utilized across several domains.

For Information exchange – JWTs are useful for securely communicating information between parties since they may be signed, ensuring that the senders are who they claim to be. Furthermore, the form of a JWT enables you to ensure that the content has not been tampered with.

Because of its tiny size, a JWT may be supplied by a URL, a POST parameter, or inside an HTTP header and is swiftly transferred. A JWT provides all of the necessary information about an entity to avoid asking a database multiple times. A JWT receiver is also not required to call a server to validate the token.

Structure of a JWT

A typical JWT looks as follows:

xxxxx.yyyyy.zzzzz

A JWT is made up of 3 parts:

1. Header: The header is made up of 2 parts:
   • The signing algorithm that’s being used.
   • The type of token.
2. Payload: The claims or the JSON object are contained in the payload. Claims are statements about an entity (typically, the user) and additional data. There are three types of claims: registered, public, and private claims.
3. Signature: is a string created by a cryptographic technique that may be used to validate the JSON payload’s integrity.

All the above 3 parts after construction are Base64 encoded URL strings separated by dots that can be easily passed in HTML and HTTP environments, while being more compact when compared to XML-based standards such as SAML.

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

WebAuthn

JWT
WebAuthn is core component of the FIDO2 framework, a set of technologies that enable passwordless authentication between servers, browsers, and authenticators.

The Web Authentication API (also known as WebAuthn) is a specification written by the World Wide Web Consortium W3C and FIDO, with the participation of Google, Mozilla, Microsoft, Yubico, and others. This API allows applications and systems to register and authenticate users using public key cryptography instead of a password.

FIDO’s robust security comes from the use of cryptographic login credentials that are unique across every website, never leave the user’s device and are never stored on a server. This security model eliminates the risks of phishing, all forms of password theft and replay attacks.

As of January 2019, WebAuthn is supported on Chrome, Firefox, and Edge, and Safari.

WebAuth depends on three important properties:

1. Strong- A Hardware Security Module is the suitable foundation for authentication since it can securely store private keys and carry out the cryptographic operations required by WebAuthn.
2. Scope- The keypair generated during registration is only useful for a specific origin, similar to how browser uses cookies. A keypair registered at ‘gmail.com’ cannot be used at ‘fakegmail.com’, mitigating the threat of phishing.
3. Attested – Servers can use a certificate provided by authenticators to confirm that the public key indeed originated from an authenticator they trust and not from a fake source.

WebAuthn: Wave of the Future

The future of secure authentication looks to be passwordless, and WebAuthn undoubtedly offers the necessary foundation to take that step.

LDAP Authentication

The Lightweight Directory Access Protocol (LDAP) is a vendor neutral, open, cross-platform software protocol used primarily for directory and authentication services.

LDAP is widely used to access central authentication servers. These servers store usernames and passwords for all the users within a network. Applications and services can connect to the LDAP server to authenticate and authorize users.

LDAP directories often contain data that is frequently accessed, but rarely changed. LDAP is designed to deliver incredibly fast READ performance, even for huge datasets. However, the WRITE performance is significantly lower.

Verifying users and passwords kept in a directory service, such as OpenLDAP or Microsoft Active Directory, is known as LDAP authentication. Administrators can create user accounts within a directory and grant them permissions.

LDAP and Active Directory

Although they are not the same thing, LDAP and Active Directory are sometimes used interchangeably. Microsoft created the exclusive directory service known as Active Directory. It can be used to store data about network resources or for authentication. One of the protocols used to generate or search for items in Active Directory is LDAP.

In a nutshell, LDAP is a language used to communicate with directory services, of which Active Directory is one.

Single Sign On (SSO)

SSO is an authentication solution that allows users to safely authenticate with numerous apps and websites using a single set of credentials.

SSO may be used by companies, small and medium-sized businesses, and individuals to help them manage various credentials.

Frameworks, Concepts and standards of SSO

1. Federated Identity Management
2. OAuth 2.0
3. Open ID Connect (OIDC)
4. Security Assertion Markup Language(SAML)

SSO Principle

SSO operates on the basis of a trust relationship established between an application, known as the service provider, and an identity provider, such as Okta, OneLogin etc. This trust relationship is frequently founded on the exchange of a certificate between the identity supplier and the service provider. This certificate can be used to certify identity information transmitted from the identity provider to the service provider, ensuring that it comes from a trustworthy source. In SSO, this identity data is represented by tokens, which contain identifying information about the user, such as an email address or a username.

Identity Provider – IDP

A service that saves and manages digital identities is known as an identity provider (IdP).

Organizations utilize these services to link their staff or users to the resources they require. They allow you to control access by adding or deleting rights while maintaining security.

The IdP can authenticate the user directly or provide authentication services to third-party service providers (apps, websites, or other digital services).

A user is referred to as a principal by an IdP. A principal can be either a person or a machine. Any entity, including devices, can be authenticated by an IdP. An IdP’s objective is to track these entities and know where and how to get the primary IDs that decide whether a person or device has access to sensitive data.

In a nutshell, an IdP provides user authentication as a service. You can, for example, check in to booking.com using your Google account credentials. In this case, your Google Sign-In serves as the IdP, while booking.com serves as the service provider (SP). An IdP is used to authenticate users on any website that requires a login, for example. To authenticate the user, a password or another authentication factor may be used.

IDP Initiated authentication

In an IdP-initiated authentication, users authenticates through the login screen of the IDP, where their user credentials are stored. After successful login, users are presented with a privileged application catalog on their dashboard, displaying visual icons of all the internal and external applications that the admin has configured for SSO access by the end user.

The Authentication flow is as follows when the user clicks on any of the available application icons:

1. The subject users’ identity and some other details are sent by the Identity Provider (IdP) to the Service Provider (SP).
2. The IdP creates an XML document called SAML Assertion, which contains the information sent by the IdP to the SP.
3. The IdP uses a private key to sign the SAML Assertion document. This key was shared between the IdP and SP when they established SSO trust.
4. The IdP sends the SAML Assertion to the SP using the user’s browser, or it sends a reference that the SP can use to securely retrieve the SAML Assertion.

OAuth

OAuth is an open-standard authorization protocol or framework that provides applications the ability for “secure designated access”.

OAuth operates via HTTPS and uses access tokens rather than credentials to authorize devices, APIs, servers, and apps.

Eg:- You can inform Facebook that sportssite.com is permitted to view your profile or make updates to your timeline without providing ESPN with your Facebook login. This significantly reduces risk: In the event that sportssite.com is hacked, your Facebook login is protected.

OAuth comes in two flavors: OAuth 1.0a and OAuth 2.0. These specifications are fully incompatible with one another and cannot be used together: there is no backwards compatibility.

OAuth 2.0 is the most used type of OAuth.

Oauth 2.0 Roles

The concept of roles is part of the OAuth2.0 authorization framework’s core definition. These are the components that define an OAuth 2.0 system and are as follows:

Resource Owner: The individual or system that owns the protected resources and may provide access to them is known as the resource owner.

Client: The client is the system that needs to access the protected resources. The Client must have the right Access Token in order to access resources.

Authorization Server: This server accepts Access Token requests from the Client and issues them after successful authentication and approval by the Resource Owner. The authorization server exposes two endpoints: the Authorization endpoint, which handles the user’s interactive authentication and consent, and the Token endpoint, which handles machine-to-machine interaction

Resource server: A server that safeguards the user’s resources and responds to Client access requests. It takes and validates the Client’s Access Token and returns the necessary resources to it.

Mechanics of Oauth2.0

Before using OAuth 2.0, the Client must first get its own credentials, a client_id and client_secret, from the Authorization Server in order to identify and authenticate itself when requesting an Access Token.

The Client, for example, a mobile app, website, smart TV app, desktop application, etc., initiates access requests using OAuth 2.0. This is the usual flow of the token request, exchange, and response:

1. The Client makes an authorization request from the Authorization server, providing the client id and secret as identity, as well as the scopes and an endpoint URI (redirect URI) to which the Access Token or the Authorization Code should be sent.
2. The Authorization server checks the requested scopes and authenticates the Client.
3. To gain access, the Resource owner communicates with the Authorization server.
4. Depending on the grant type, the Authorization server returns to the Client with either an Authorization Code or an Access Token. In addition, a Refresh Token may be returned.
5. The Client uses the Access Token to request access to the resource from the Resource server.

OIDC

OpenID Connect, often known as OIDC, is an identity protocol that makes use of OAuth 2.0’s authorization and authentication features.

It enables third-party apps like single-page applications to native and mobile apps to validate the end-user’s identification and receive basic user profile information. OIDC employs JSON web tokens (JWTs), which may be obtained using OAuth 2.0-compliant processes.

OIDC specification was developed by the OpenID Foundation, which includes tech giants like Google and Microsoft.

Comparing OIDC and OAuth2.0

While OAuth 2.0 is concerned with resource access and sharing, OIDC is concerned with user authentication. Its objective is to provide you with a single login for many sites. When you use OIDC to log in to a website, you are sent to your OpenID site, where you log in, and then returned to the webpage. For example, if you signed in to booking.com with your Google account, you used OIDC. When you successfully authenticate with Google and grant Auth0 access to your information, Google transmits information about the user and the authentication to Auth0. This data is returned in the form of a JWT. You will be given an access token and, if necessary, an ID token.

Terminology

The OIDC Provider – It’s an Identity Provider (IDP) which performs user authentication, users consent and token issuance.

Relying Party (RP) – The client(applications) or service requesting a user’s identity is known as the Relying Party(RP)

ID Token – This token in JWT format is primarily used by OIDC to convey information about the conclusion of the authentication procedure. It may offer identifying data characterizing a user profile upon request. Claims are the data concerning the authentication result and the user profile information. Any data that is relevant to the Relying Party for identifying purposes, such as a persistent ID, email address, name, and so on, may be claimed as a user profile claim.

Access Token – Access Token is a short lifetime token providing access to specific user resources as defined in the scope values in the request to the authorization server

Refresh Token – Refresh tokens are usually long-lived and may be used to obtain new access tokens.

OIDC Flows

1. Implicit Flow: Tokens are returned straight to the Relying Party in a redirect URI in this flow, which is often used by SPAs.
2. Authorization Code Flow: Because tokens are not returned directly, this flow is more secure than Implicit. The use of Proof Key for Code Exchange (PKCE) can improve security in native/mobile applications and SPA.
3. Hybrid Flow: Combining the Implicit and Authorization Code flows, the ID Token is returned to the RP directly, but the access token is not. Instead, an authorization code is returned, which is used to get an access token.

Also Read: Authentication and Authorization-Terminology, Authentication and Authorization Section