APIs handle enormous amounts of data of a widely varying type – accordingly, one of the chief concerns of any data provider is how specifically to secure this data. The idea that data should be secret, that it should be unchanged, and that it should be available for manipulation is key to any conversation on API data management and handling.

Today, we’re going to talk about Authentication. Though an often discussed topic, it bears repeating to clarify exactly what it is, what it isn’t, and how it functions.

We’ll highlight three major methods of adding security to an API — HTTP Basic Auth, API Keys, and OAuth. We’ll identify the pros and cons of each approach to authentication, and finally recommend the best way for most providers to leverage this power.

Authentication vs Authorization
Before we dive into this topic too deep, we first need to define what authentication actually is, and more importantly, what it’s not. As much as authentication drives the modern internet, the topic is often conflated with a closely related term: authorization.

The two functions are often tied together in single solutions – in fact, one of the solutions we’re going to discuss in a moment is a hybrid system of authentication and authorization. As such, and due to their similarities in functional application, it’s quite easy to confuse these two elements.

The easiest way to divide authorization and authentication is to ask: what do they actually prove? In simple terms, Authentication is when an entity proves an identity. In other words, Authentication proves that you are who you say you are. This is akin to having an identification card – an item given by a trusted authority that the requester, such as a police officer, can use as evidence that suggests you are in fact who you say you are.

Authorization is an entirely different concept, though it is certainly closely related. In simple terms, Authorization is when an entity proves a right to access. In other words, Authorization proves you have the right to make a request. When you try to go backstage at a concert or an event, you don’t necessarily have to prove that you are who you say you are – you furnish the ticket, which is de facto proof that you have the right to be where you’re trying to get into.

Consider for a moment a driver’s license. In many countries, a driver’s license proves both that you are who you say you are via a picture or other certified element, and then goes further to prove that you have a right to drive the vehicle class you’re driving. In such a case, we have authentication and authorization – and in many API solutions, we have systems that give a piece of code that both authenticates the user and proves their authorization. In such a case, we have hybrid solutions.

Therefore, moving forward, it’s important to remember that what we’re actually talking about here is a system that proves your identity – nothing more, nothing less.

Related: How To Control User Identity Within Microservices

Common Methods of API Authentication
While there are as many proprietary authentication methods as there are systems which utilize them, they are largely variations of a few major approaches. These approaches almost always were developed to solve limitations in early communications and internet systems, and as such, typically use broad existent architectural approaches with novel implementations in order to allow authentication to occur.

HTTP Basic Authentication

HTTP Basic Auth is rarely recommended due to its inherent security vulnerabilities.

One solution is that of HTTP Basic Authentication. In this approach, an HTTP user agent simply provides a username and password to prove their authentication. This approach does not require cookies, session IDs, login pages, and other such specialty solutions, and because it uses the HTTP header itself, there’s no need to handshakes or other complex response systems.

The problem is that, unless the process is strictly enforced throughout the entire data cycle to SSL for security, the authentication is transmitted in open on insecure lines. This lends itself to man in the middle attacks, where a user can simply capture the login data and authenticate via a copy-cat HTTP header attached to a malicious packet.

Additionally, even if SSL is enforced, this results in a slowing of the response time. And even ignoring that, in its base form, HTTP is not encrypted in any way. It is encapsulated in base64, and is often erroneously proclaimed as encrypted due to this.

HTTP Basic Authentication does have its place. In an internal network, especially in IoT situations where speed is of no essence, having an HTTP Basic Authentication system is acceptable as a balance between cost of implementation and actual function. As a general authentication solution, however, HTTP Basic Authentication should be seldom used in its base form.

Read more: Maintaining Security In A Continuous Delivery Environment

API Keys

API keys are an industry standard, but shouldn’t be considered a holistic security measure.

API Keys were created as somewhat of a fix to the early authentication issues of HTTP Basic Authentication and other such systems. In this approach, a unique generated value is assigned to each first time user, signifying that the user is known. When the user attempts to re-enter the system, their unique key (sometimes generated from their hardware combination and IP data, and other times randomly generated by the server which knows them) is used to prove that they’re the same user as before.

On one hand, this is very fast. The ability to prove identity once and move on is very agile, and is why it has been used for many years now as a default approach for many API providers. Additionally, setting up the system itself is quite easy, and controlling these keys once generated is even easier. This also allows systems to purge keys, thereby removing authentication after the fact and denying entry to any system attempting to use a removed key.

The problem, however, is that API keys are often used for what they’re not – an API key is not a method of authorization, it’s a method of authentication. Because anyone who makes a request of a service transmits their key, in theory, this key can be picked up just as easy as any network transmission, and if any point in the entire network is insecure, the entire network is exposed. This makes API keys a hard thing to recommend – often misused and fundamentally insecure, they nonetheless do have their place when properly secured and hemmed in by authorization systems.

Read more: Why API Keys ≠ API Security

OAuth

OAuth combines Authentication and Authorization to allow more sophisticated scope and validity control.

OAuth is a bit of a strange beast. OAuth is not technically an authentication method, but a method of both authentication and authorization. When OAuth is used solely for authentication, it is what is referred to as “pseudo-authentication.”

In this approach, the user logs into a system. That system will then request authentication, usually in the form of a token. The user will then forward this request to an authentication server, which will either reject or allow this authentication. From here, the token is provided to the user, and then to the requester. Such a token can then be checked at any time independently of the user by the requester for validation, and can be used over time with strictly limited scope and age of validity.

This is fundamentally a much more secure and powerful system than the other approaches, largely because it allows for the soft establishment of scope (that is, what systems the key allows the user to authenticate to) and validity (meaning the key doesn’t have to be purposely revoked by the system, it will automatically become deprecated in time).

As with anything, there are some major pros and cons to this approach. On the one hand, it’s clearly superior when it comes to the level of security it can offer, and for this reason, OAuth is quickly becoming the de facto choice for anyone choosing to eschew API keys. On the other hand, using OAuth for authentication alone is ignoring everything else that OAuth has to offer – it would be like driving a Ferrari as an everyday driver, and never exceeding the residential speed limits.

Those caveats in mind, OAuth is easy to set up, and it is incredibly fast.

Read more: Deep Dive Into OAuth and OpenID Connect

The Best Option
So of these three approaches, two more general and one more specific, what is the best? That’s a hard question to answer, and the answer itself largely depends on your situations. While the clear winner of the three approaches is OAuth, there are some use cases in which API keys or HTTP Basic Authentication might be appropriate.

That being said, these use cases are few and far in-between, and accordingly, it’s very hard to argue against OAuth at the end of the day. OAuth delivers a ton of benefits, from ease of use to a federated system module, and most importantly offers scalability of security – providers may only be seeking authentication at this time, but having a system that natively supports strong authorization in addition to the baked-in authentication methods is very valuable, and decreases cost of implementation over the long run.

What do you think? What’s the best way to authenticate a user? More to the point, what do you think are the most clear use cases for using something like an API key over OAuth? Let us know in the comments below.

[/su_tab}]

Authentication & Authorization

https://www.moesif.com/blog/technical/restful-apis/Authorization-on-RESTful-APIs/#:~:text=Authentication%20%26%20Authorization&text=Involves%20checking%20resources%20that%20the,be%20applied%20to%20your%20API.

Steps to building authentication and authorization for RESTful APIs

 

Authentication & AuthorizationPermalink

One of the challenges to building any RESTful API is having a well thought out authentication and authorization strategy. Cross cutting concerns like authentication, security, and logging are always challenging and involves many stakeholders.

To be clear on definitions, there are two separate actions usually discussed together:

Authentication:Permalink

Involves verifying who the person says he/she is. This may involve checking a username/password or checking that a token is signed and not expired. Authentication does not say this person can access a particular resource.

Authorization:Permalink

Involves checking resources that the user is authorized to access or modify via defined roles or claims. For example, the authenticated user is authorized for read access to a database but not allowed to modify it. The same can be applied to your API. Maybe most users can access certain resources or endpoints, but special admin users have privileged access.

Of course, these definitions are usually implemented together and interdependent, so when we refer to auth, we are referring to the overall system.

Defining the actual tokenPermalink

One of the first things to give thought to when creating an auth strategy is what type of token you will use. There are a variety of methods, but two of the most common are:

1. JWT Tokens (JSON Web Tokens)Permalink

JWT Tokens are actually a full JSON Object that has been base64 encoded and then signed with either a symmetric shared key or using a public/private key pair. The difference is if you have a consumer that needs to verify the token is signed, but that consumer shouldn’t be allowed to create tokens, you can give the consumer the public key which can’t create tokens but still verify them. I’ll save the details for a separate post, but if you remember from your cryptography courses, asymmetric encryption and signature algorithms create a pair of keys that are mathematically related.

The JWT can contain such information include the subject or user_id, when the token was issued, and when it expires. By signing with a secret, you ensure that only you can generate a token and thus was not tampered with (such as modifying the user_id or when it expires). One thing to keep in mind though, while the JWT is signed, JWTs are usually not encrypted (although you can encrypt it optionally). This means any data that is in the token can be read by anyone who has access to the token. It is good practice to place identifiers in the token such as a user_id, but not personally identifiable information like an email or social security number. You can use a tool like JWT.io to easily base64 decode and view the JSON data.

Why are JWTs so great?Permalink

One of the benefits of JWTs is they can be used without a backing store. All the information required to authenticate the user is contained within the token itself. In a distributed microservice world, it makes it easy to not rely on centralized authentication servers and databases. The individual microservice only needs some middleware to handle verifying the token (JWT libs are openly available for everything from Express to JVM MVC Frameworks) and also the secret key needed to verify. Verifying consists of checking signature and a few parameters such as the claims and when the token expires. JWTs are usually medium life tokens with an expiration date that may set anywhere from a few weeks to longer

Verifying that a token is correctly signed only takes CPU Cycles and requires no IO or network access and very easy to scale on modern web server hardware.

If JWTs are so great why doesn’t everyone use them?Permalink

One of the downsides with JWTs is that banning users or adding/removing roles is a little harder if you need the action to be immediate. Remember, the JWT has a predefined expiration date which may be set a week into the future. Since the token is stored client side, there is no way to directly invalidate the token even if you mark the user as disabled in your database. Rather, you must wait until it expires. This can influence your architecture especially if designing a public API that could be starved by one power user or an e-commerce app where fraudulent users need to be banned. There are workarounds, for example, if all you care is banning compromised tokens or users, you can have a blacklist of tokens or user_ids, but this may reintroduce a database back into your auth framework. A recommended way to blacklist is to ensure each token has a jti claim (or a JWT Id which can be stored in the Db) Assuming that the number of tokens you would like to invalidate is much smaller than the number of users in your application, this may scale pretty easily. You may even locally cache it in the same process as your API code removing some dependency on a database server being multiple 9’s of reliability.

On the other hand, if you have an enterprise app with many roles such as admin, project owner, service account manager and you want the effect to have immediate effect, then development can be tricky. Especially, think of the case where an admin is modifying someone else’s authorized roles such as his/her immediate reports. Thus, the modified user doesn’t even know his/her roles have changed without refreshing the JWT.

A second downside is the token can grow as more fields are added. In stateless apps, the token is sent for pretty much every request, thus there can be an impact on data traffic size. For example, the enterprise app we referred to earlier may have many roles, which may add bloat and complications for what to store in a token. Think of designing the APIs that back AWS or Azure’s Web Portal. You have targeted permissions on each resource for each user. For example, thus one user is allowed to view S3 accounts, but not modify EC2 instances. The sheer complexity of this may be beyond what a JWT can handle.

In mobile apps where smartphone owners are concerned for client side latency and data usage, JWTs may add too much payload to each request.

2. Opaque TokensPermalink

Now that we discussed the benefits and drawbacks of JWTs, let’s explore a secondary option, Opaque Tokens. Opaque tokens are literally what they sounds like. Instead of storing user identity and claims in the token, the opaque token is simply a primary key that references a database entry which has the data. Fast key value stores like Redis are perfect for leveraging in memory hash tables for O(1) lookup of the payload. Since the roles are read from a database directly, roles can be changed and the user will see the new roles as soon as the changes propagate through your backend.

Of course, there is the added complexity of maintaining the K/V store and the auth server. Depending on your architecture, each service has to handshake with the auth server to get the claims or roles.

3. A blendPermalink

One thing not talked about yet is a blend of both options. You can handle authentication via JWT such as checking that the user is who they say they are. On the other hand, authorization for specific resources are not part of the JWT. In other words, the JWT only handles the authentication side but not authorization side.

Monitor and Secure your APIs in minutes with Moesif

Learn More

Cookies vs. Headers vs. URL ParameterPermalink

URL ParametersPermalink

First of all, we never recommend placing a token in the URL. URLs are bookmarked, shared with friends, posted online, etc. It is too easy for a user to copy a URL of a page they like and forward to a friend. Now, the friend has all the authentication requirements needed to sign in on behalf of that user. In addition, there are a variety of other concerns such as most loggers will log the URL in plain text at a minimum. It’s much less likely for someone to open developer tools in Chrome and copy their cookie or HTTP headers 😉

So this narrows us down to only Cookies vs HTTP Headers. If you are focused on creating RESTful APIs, really the Cookie is just another header just like the Authorization Header. You could in fact take the same JWT that would be sent via an Authorization Header and wrap it in a cookie. In reality, many pure RESTful APIs designed for consumption by others just use a standard or custom authorization header as it is more explicit. There can also be a blend, for example a web app may talk to a RESTful API behind a proxy using Cookies. The proxy will extract the Cookie and add the appropriate headers when relaying the request. The real reasons come in the next section:

The real debate: Cookie vs. Local Storage:Permalink

While the cookie may in fact just wrap the JWT or opaque token, a client web app still has to store the token somewhere. The two choices that most people think of is Cookies and HTML5 Local Storage. So sometimes when people refer to Cookie vs HTTP Header, they are actually asking “Cookie vs. Local Storage?” There are benefits and security risks for each.

CookiesPermalink

Cookies can be nice as they have certain flags that can be set to enforce security checks such as HTTP Only and Secure. By setting HTTP Only and Secure flags, the cookie cannot be read by any Javascript code nor be sent in plain text over HTTP. Thus the Cookie can be immune to XSS attacks as described in the local storage Section. Cookies can be vulnerable to a different type of attack called cross site request forgery (XSRF or CSRF). XSRF means a hacker on a different site can replicate some input form on your own site and POST form data to our own site. While the hacker doesn’t have access to the cookie itself, cookies are transferred with every HTTP request to your real domain that the cookie is valid for. Thus, the hacker doesn’t need to read the cookie, it just needs to successfully POST form data to your real site. This is one of the dangers with cookies. They are sent for every request, static, AJAX, etc. There are ways around this, but the fundamental principal is that your web server needs to recognize whether the request came from your real website running in a browser or someone else. One way to do this is with a hidden anti-forgery token. One way is to generate and store a special random key in the cookie that also needs to be sent with the POSTed form data. Remember, only your real site can access the cookie but the hacker site cannot due to same origin policy. Your server can then verify that the cookie’s token matches the token in form data. There are other options for protection on XSRF.

Local StoragePermalink

A security risk for local storage is Javascript can be subject to Cross-Scripting attacks (XSS). In the early days, XSS was a result of not escaping user input, but now your modern web app probably imports numerous JS libs from analytics and attribution tracking to ads and small UI elements. Local storage is global to your website domain. Thus, any javascript on your website, 3rd party lib or not, can access the same local storage. There is no sandboxing within your app. For example, your analytics lib reads and writes from the same local storage as your own application code. While GA is probably fine, did you audit that quick UI element you added? In the past, there was also concern if javascript made AJAX calls in plain text even though the website itself was secured via HTTPS. This concern is less than it used to now that browsers are starting to enforce checks for mixed content. Something to still be aware of incase a browser is older or launched without enforcement.

A second downside for local storage is you can’t access it across multiple subdomains. If you have a separate blog subdomain or email subdomain, these sites cannot read the local storage. This might be fine if you don’t plan on logging in across multiple domains (Think mail.google.com and google.com).

ThanksPermalink

We’re thankful to our select beta customers who have been trying out Moesif providing us invaluable feedback to make debugging easier.

https://blog.restcase.com/4-most-used-rest-api-authentication-methods/

4 Most Used REST API Authentication Methods

26 JULY 2019 on RestCase, REST API Security, REST API, OAS, API Driven Development

While there are as many proprietary authentication methods as there are systems which utilize them, they are largely variations of a few major approaches. In this post, I will go over the 4 most used in the REST APIs and microservices world.

Authentication vs Authorization

Before I dive into this, let's define what authentication actually is, and more importantly, what it’s not. As much as authentication drives the modern internet, the topic is often conflated with a closely related term: authorization.

The two functions are often tied together in single solutions, but the easiest way to divide authorization and authentication is to ask: what do they actually state or prove about me?

Authentication is when an entity proves an identity. In other words, Authentication proves that you are who you say you are. This is like having a driver license which is given by a trusted authority that the requester, such as a police officer, can use as evidence that suggests you are in fact who you say you are.

Authorization is an entirely different concept and in simple terms, Authorization is when an entity proves a right to access. In other words, Authorization proves you have the right to make a request. Consider the following – You have a working key card that allows you to open only some doors in the work area, but not all of them.

In summary:
Authentication: Refers to proving correct identity
Authorization: Refers to allowing a certain action

An API might authenticate you but not authorize you to make a certain request.

Now that we know what authentication is, let's see what are the most used authentication methods in REST APIs.

4 Most Used Authentication Methods

Let's review the 4 most used authentication methods used today.

1. HTTP Authentication Schemes (Basic & Bearer)

The HTTP Protocol also defines HTTP security auth schemes like:

• Basic
• Bearer
• Digest
• OAuth
  and others…

We will go over the two most popular used today when discussing REST API.

Basic Authentication

HTTP Basic Authentication is rarely recommended due to its inherent security vulnerabilities.

This is the most straightforward method and the easiest. With this method, the sender places a username:password into the request header. The username and password are encoded with Base64, which is an encoding technique that converts the username and password into a set of 64 characters to ensure safe transmission.

This method does not require cookies, session IDs, login pages, and other such specialty solutions, and because it uses the HTTP header itself, there’s no need to handshakes or other complex response systems.

Here’s an example of a Basic Auth in a request header:
Authorization: Basic bG9sOnNlY3VyZQ==

Bearer Authentication

Bearer authentication (also called token authentication) is an HTTP authentication scheme that involves security tokens called bearer tokens.

The name “Bearer authentication” can be understood as “give access to the bearer of this token.” The bearer token allowing access to a certain resource or URL and most likely is a cryptic string, usually generated by the server in response to a login request.

The client must send this token in the Authorization header when making requests to protected resources:
Authorization: Bearer <token>

The Bearer authentication scheme was originally created as part of OAuth 2.0 in RFC-6750 but is sometimes also used on its own.

Similarly to Basic authentication, Bearer authentication should only be used over HTTPS (SSL).

2. API Keys

In REST API Security – API keys are widely used in the industry and became some sort of standard, however, this method should not be considered a good security measure.

API Keys were created as somewhat of a fix to the early authentication issues of HTTP Basic Authentication and other such systems. In this method, a unique generated value is assigned to each first time user, signifying that the user is known. When the user attempts to re-enter the system, their unique key (sometimes generated from their hardware combination and IP data, and other times randomly generated by the server which knows them) is used to prove that they’re the same user as before.

Many API keys are sent in the query string as part of the URL, which makes it easier to discover for someone who should not have access to it. Please do not put any API keys or sensitive information in query string parameters! A better option is to put the API key in the Authorization header. In fact, that’s the proposed standard: Authorization: Apikey 1234567890abcdef.

Yet, in practice API keys show up in all sorts of places:

• Authorization Header
• Basic Auth
• Body Data
• Custom Header
• Query String

There are definitely some valid reasons for using API Keys. First and foremost, API Keys are simple. The use of a single identifier is simple, and for some use cases, the best solution. For instance, if an API is limited specifically in functionality where “read” is the only possible command, an API Key can be an adequate solution. Without the need to edit, modify, or delete, security is a lower concern.

The problem, however, is that anyone who makes a request to a service, transmits their key and in theory, this key can be picked up just as easy as any network transmission, and if any point in the entire network is insecure, the entire network is exposed.

If you are dealing with Authentication in REST APIs, please consider doing Security Testing, in order to check the common vulnerabilities.

3. OAuth (2.0)

The previous versions of this spec, OAuth 1.0 and 1.0a, were much more complicated than OAuth 2.0. The biggest change in the latest version is that it’s no longer required to sign each call with a keyed hash. The most common implementations of OAuth use one or both of these tokens instead:

• access token: sent like an API key, it allows the application to access a user’s data; optionally, access tokens can expire.
• refresh token: optionally part of an OAuth flow, refresh tokens retrieve a new access token if they have expired. OAuth2 combines Authentication and Authorization to allow more sophisticated scope and validity control.

OAuth 2.0 is the best choice for identifying personal user accounts and granting proper permissions. In this method, the user logs into a system. That system will then request authentication, usually in the form of a token. The user will then forward this request to an authentication server, which will either reject or allow this authentication. From here, the token is provided to the user, and then to the requester. Such a token can then be checked at any time independently of the user by the requester for validation and can be used over time with strictly limited scope and age of validity.

This is fundamentally a much more secure and powerful system than the other approaches, mainly because it allows for the establishment of scopes which can provide access to different parts of the API service and since the token is revoked after a certain time – makes it much harder to re-use by attackers.

OAuth 2.0 Popular Flows

The flows (also called grant types) are scenarios an API client performs to get an access token from the authorization server.

OAuth 2.0 provides several popular flows suitable for different types of API clients:

• Authorization code – The most common flow, mostly used for server-side and mobile web applications. This flow is similar to how users sign up into a web application using their Facebook or Google account.
• Implicit – This flow requires the client to retrieve an access token directly. It is useful in cases when the user’s credentials cannot be stored in the client code because they can be easily accessed by the third party. It is suitable for web, desktop, and mobile applications that do not include any server component.
• Resource owner password – Requires logging in with a username and password. Since in that case, the credentials will be a part of the request, this flow is suitable only for trusted clients (for example, official applications released by the API provider).
• Client Credentials – Intended for the server-to-server authentication, this flow describes an approach when the client application acts on its own behalf rather than on behalf of any individual user. In most scenarios, this flow provides the means to allow users to specify their credentials in the client application, so it can access the resources under the client’s control.

4. OpenID Connect

OpenID Connect is a simple identity layer on top of the OAuth 2.0 protocol, which allows computing clients to verify the identity of an end-user based on the authentication performed by an authorization server, as well as to obtain basic profile information about the end-user in an interoperable and REST-like manner.

In technical terms, OpenID Connect specifies a RESTful HTTP API, using JSON as a data format.

OpenID Connect allows a range of clients, including Web-based, mobile, and JavaScript clients, to request and receive information about authenticated sessions and end-users. The specification suite is extensible, supporting optional features such as encryption of identity data, the discovery of OpenID Providers, and session management.

OpenID Connect defines a sign-in flow that enables a client application to authenticate a user, and to obtain information (or "claims") about that user, such as the user name, email, and so on. User identity information is encoded in a secure JSON Web Token (JWT), called ID token.

– JWT

JSON Web Tokens are an open, industry-standard RFC 7519 method
for representing claims securely between two parties. JWT allows
you to decode, verify and generate JWT. While JWT is a standard it
was developed by Auth0, an API driven identity, and authentication
management company.

OpenID Connect defines a discovery mechanism, called OpenID Connect Discovery, where an OpenID server publishes its metadata at a well-known URL, typically https://server.com/openid-configuration.

This URL returns a JSON listing of the OpenID/OAuth endpoints, supported scopes and claims, public keys used to sign the tokens, and other details. The clients can use this information to construct a request to the OpenID server. The field names and values are defined in the OpenID Connect Discovery Specification.

OpenAPI Security Schemes

In OpenAPI specification, in order to define what kind of a security mechanism is used across the API – API security schemes are used to define what API resources are secured and what means.

In OpenAPI specification there are a number of standard authentication protocols you can pick from, each with their own strengths and weaknesses.

Basic API Authentication

• Easy to implement, supported by nearly all web servers
• Entails sending base-64 encoded username and passwords
• Should not be used without SSL
• Can easily be combined with other security methods

Note*: basic authentication is very vulnerable to hijacks and man-in-the-middle attacks when no encryption is in use. Due to this limitation, this method of authentication is only recommended when paired with SSL.*

OAuth1.0 (Digest Scheme)

• Popular, tested, secure, signature driven, well-defined protocol
• Uses cryptographic signature, which is a mix of a token secret, nonce, and other request based information
• Can be used with or without SSL

OAuth2 (Bearer Token Scheme)

• The current OAuth2 specification eliminates the need for cryptographic signatures, passwords, and usernames

• OAuth2 works with authentication scenarios called flows, these flows include:

  • Authorization Code flow
  • Implicit flow
  • Resource Owner Password flow
  • Client Credentials flow

OpenID Connect Discovery

• Based on the OAuth 2.0 protocol
• Uses a sign-in flow that permits user authentication and information access by a client app
• The user information is encoded via a secure JSON Web Token (JWT)

RestCase development platform, allows you to define these Security schemes visually, allowing to build and define the entire API without any coding knowledge.

Please feel free to join our Beta, just sign-up and start building APIs – It's free!

Summary

For now, the clear winner of the four methods is OAuth 2.0, there are some use cases in which API keys or HTTP Authentication methods might be appropriate and the new OpenID connect is getting more and more popular, mainly because it is based on an already popular OAuth 2.0.

OAuth 2.0 delivers a ton of benefits, from ease of use to a federated system module, and most importantly offers scalability of security – providers may only be seeking authentication at this time, but having a system that natively supports strong authorization in addition to the baked-in authentication methods is very valuable, and decreases cost of implementation over the long run.