We're going to expose a custom built API (.NET) through Azure API Management. We want to conform to well-known standards where ever possible, so we don't surprise our API consumers. The API is secured through an API key which users generate from APIM's Developer Portal.
My understanding is that the Authorization header should be used for authentication and authorization purposes.
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Authorization
But strangely, API-Key is not included as an authentication scheme.
https://www.iana.org/assignments/http-authschemes/http-authschemes.xhtml#authschemes
Should API consumers use an authorization header to authenticate?
E.g. Authorization: API-Key xxx-xxx
Or a custom header.
E.g. my-key:xxx-xxx
Technically, you shouldn't need any API-key if you have a token in the authorization header. I assume API-key/client and secret key are already used to generate a token. When the client sends token via an authorization header, the API owner validates your token and returns a response.
I have a serverless web app using AWS lambda functions. For JSON Web Token(JWT), you can specify the payload. Is it possible to specify payload like
user: example#any.com
authorization-level: admin
and use the resulting token to not only authorize users but also authenticate users? (EX. users technically do not even have to log in to access API and get personal information because token has user email, which we verify and return related payload)
Or is this a major security breach?
It is perfectly fine to use JWT for both authentication and authorization, as long as you don't use NONE for signature algorithm. The signature guarantees that user has not tampered with the payload.
I have a new SPA with a stateless authentication model using JWT. I am often asked to refer OAuth for authentication flows like asking me to send 'Bearer tokens' for every request instead of a simple token header but I do think that OAuth is a lot more complex than a simple JWT based authentication. What are the main differences, should I make the JWT authentication behave like OAuth?
I am also using the JWT as my XSRF-TOKEN to prevent XSRF but I am being asked to keep them separate? Should I keep them separate? Any help here will be appreciated and might lead to a set of guidelines for the community.
TL;DR
If you have very simple scenarios, like a single client application, a single API then it might not pay off to go OAuth 2.0. On the other hand, if there are lots of different clients (browser-based, native mobile, server-side, etc) then sticking to OAuth 2.0 rules might make it more manageable than trying to roll your own system.
As stated in another answer, JWT (Learn JSON Web Tokens) is just a token format. It defines a compact and self-contained mechanism for transmitting data between parties in a way that can be verified and trusted because it is digitally signed. Additionally, the encoding rules of a JWT also make these tokens very easy to use within the context of HTTP.
Being self-contained (the actual token contains information about a given subject), they are also a good choice for implementing stateless authentication mechanisms (aka Look mum, no sessions!). When going this route, the only thing a party must present to be granted access to a protected resource is the token itself, and the token in question can be called a bearer token.
In practice, what you're doing can already be classified as bearer token -based. However, do consider you're not using bearer tokens as specified by the OAuth 2.0 related specs (see RFC 6750). That would imply relying on the Authorization HTTP header and using the Bearer authentication scheme.
Regarding the use of the JWT to prevent CSRF: Without knowing exact details it's difficult to ascertain the validity of that practice. To be honest, it does not seem correct and/or worthwhile. The following article (Cookies vs Tokens: The Definitive Guide) may be a useful read on this subject, particularly the XSS and XSRF Protection section.
One final piece of advice. Even if you don't need to go full OAuth 2.0, I would strongly recommend on passing your access token within the Authorization header instead of going with custom headers. If they are really bearer tokens, follow the rules of RFC 6750. If not, you can always create a custom authentication scheme and still use that header.
Authorization headers are recognized and specially treated by HTTP proxies and servers. Thus, the usage of such headers for sending access tokens to resource servers reduces the likelihood of leakage or unintended storage of authenticated requests in general, and especially Authorization headers.
(source: RFC 6819, section 5.4.1)
OAuth 2.0 defines a protocol, i.e. specifies how tokens are transferred, JWT defines a token format.
OAuth 2.0 and "JWT authentication" have similar appearance when it comes to the (2nd) stage where the Client presents the token to the Resource Server: the token is passed in a header.
But "JWT authentication" is not a standard and does not specify how the Client obtains the token in the first place (the 1st stage). That is where the perceived complexity of OAuth comes from: it also defines various ways in which the Client can obtain an access token from something that is called an Authorization Server.
So the real difference is that JWT is just a token format, OAuth 2.0 is a protocol (that may use a JWT as a token format).
Firstly, we have to differentiate JWT and OAuth. Basically, JWT is a token format. OAuth is an authorization protocol that can use JWT as a token. OAuth uses server-side and client-side storage. If you want to do real logout you must go with OAuth2. Authentication with JWT token can not logout actually. Because you don't have an Authentication Server that keeps track of tokens. If you want to provide an API to 3rd party clients, you must use OAuth2 also. OAuth2 is very flexible. JWT implementation is very easy and does not take long to implement. If your application needs this sort of flexibility, you should go with OAuth2. But if you don't need this use-case scenario, implementing OAuth2 is a waste of time.
XSRF token is always sent to the client in every response header. It does not matter if a CSRF token is sent in a JWT token or not, because the CSRF token is secured with itself. Therefore sending CSRF token in JWT is unnecessary.
JWT (JSON Web Tokens)- It is just a token format. JWT tokens are JSON encoded data structures contains information about issuer, subject (claims), expiration time etc. It is signed for tamper proof and authenticity and it can be encrypted to protect the token information using symmetric or asymmetric approach. JWT is simpler than SAML 1.1/2.0 and supported by all devices and it is more powerful than SWT(Simple Web Token).
OAuth2 - OAuth2 solve a problem that user wants to access the data using client software like browse based web apps, native mobile apps or desktop apps. OAuth2 is just for authorization, client software can be authorized to access the resources on-behalf of end user using access token.
OpenID Connect - OpenID Connect builds on top of OAuth2 and add authentication. OpenID Connect add some constraint to OAuth2 like UserInfo Endpoint, ID Token, discovery and dynamic registration of OpenID Connect providers and session management. JWT is the mandatory format for the token.
CSRF protection - You don't need implement the CSRF protection if you do not store token in the browser's cookie.
It looks like everybody who answered here missed the moot point of OAUTH
From Wikipedia
OAuth is an open standard for access delegation, commonly used as a way for Internet users to grant websites or applications access to their information on other websites but without giving them the passwords.[1] This mechanism is used by companies such as Google, Facebook, Microsoft and Twitter to permit the users to share information about their accounts with third party applications or websites.
The key point here is access delegation. Why would anyone create OAUTH when there is an id/pwd based authentication, backed by multifactored auth like OTPs and further can be secured by JWTs which are used to secure the access to the paths (like scopes in OAUTH) and set the expiry of the access
There's no point of using OAUTH if consumers access their resources(your end points) only through their trusted websites(or apps) which are your again hosted on your end points
You can go OAUTH authentication only if you are an OAUTH provider in the cases where the resource owners (users) want to access their(your) resources (end-points) via a third-party client(external app). And it is exactly created for the same purpose though you can abuse it in general
Another important note:
You're freely using the word authentication for JWT and OAUTH but neither provide the authentication mechanism. Yes one is a token mechanism and the other is protocol but once authenticated they are only used for authorization (access management). You've to back OAUTH either with OPENID type authentication or your own client credentials
find the main differences between JWT & OAuth
OAuth 2.0 defines a protocol & JWT defines a token format.
OAuth can use either JWT as a token format or access token which is a bearer token.
OpenID connect mostly use JWT as a token format.
JWT is an open standard that defines a compact and self-contained way for securely transmitting information between parties. It is an authentication protocol where we allow encoded claims (tokens) to be transferred between two parties (client and server) and the token is issued upon the identification of a client. With each subsequent request we send the token.
Whereas OAuth2 is an authorization framework, where it has a general procedures and setups defined by the framework. JWT can be used as a mechanism inside OAuth2.
You can read more on this here
OAuth or JWT? Which one to use and why?
Jwt is a strict set of instructions for the issuing and validating of signed access tokens. The tokens contain claims that are used by an app to limit access to a user
OAuth2 on the other hand is not a protocol, its a delegated authorization framework. think very detailed guideline, for letting users and applications authorize specific permissions to other applications in both private and public settings. OpenID Connect which sits on top of OAUTH2 gives you Authentication and Authorization.it details how multiple different roles, users in your system, server side apps like an API, and clients such as websites or native mobile apps, can authenticate with each othe
Note oauth2 can work with jwt , flexible implementation, extandable to different applications
JWT tokens require, at most, a one-time communication between the resource server and the authorization server at runtime. The
resource server needs to request the authorization server for the
public key to decrypt the JWT tokens. This can be done at resource
server startup. This can even be stored in the resource server in a
properties file avoiding the query at all.
OAuth2 solve a problem that user wants to access the data using client software like browser-based web apps, native mobile apps, or
desktop apps. OAuth2 is just for authorization, client software can
be authorized to access the resources on behalf of end-user using an
access token.
OAuth2 can be used with JWT tokens or access token which is a bearer
token.
I've been looking at using oauth2 client credentials grant to secure my API (all users will be trusted 3rd parties). I'm following the same approach as paypal here: https://developer.paypal.com/docs/integration/direct/paypal-oauth2/
However, I see that HTTP:// basic auth is used to acquire a bearer token. Then the bearer token is used to secure the API calls.
What I don't understand is, if you're going to trust TLS and http: basic auth to retrieve the bearer token - why not just use http: basic auth for the API calls? What is the benefit of using bearer tokens?
What am I missing?
Adding to what Ankit Saroch is saying, going the OAuth way with Tokens may open up other possibilities in the future; say you may want to extend the flow to include User information. By only validating tokens, this means you will probably not need to change the token validation (which is simple) in your service, but rather only the authentication and authorization steps.
But obviously you're right in what you are saying: The Client Credentials OAuth Flow is not more secure than simply using techniques like API Keys or Basic Authentication. All of those rely on the Client being confidential (it can keep its credentials to itself).
The OAuth Spec (https://www.rfc-editor.org/rfc/rfc6749#section-2.1) talks about these Client Types. In total, it's worth reading the spec actually.
As per The OAuth 2.0 Authorization Framework: Bearer Token Usage
The access token provides an abstraction, replacing different
authorization constructs (e.g., username and password, assertion) for
a single token understood by the resource server. This abstraction
enables issuing access tokens valid for a short time period, as well
as removing the resource server's need to understand a wide range of
authentication schemes.
The server that is authorizing the request and giving you the Bearer Token, may be different from the server that actually controls the resources that you are trying to access.
As per the RFC, they have been shown as two different entities. The one giving you the Bearer Token is Authorization Server and the one serving the resources is Resource Server.
Although I have worked with OAuth 2 before, I am a newbie to Open ID Connect.
Reading the tutorials and documentations I have come across both access_token and id_token where access_token is the random unique string generated according to OAuth 2 and id_token is JSON Web Token which contains information like the id of the user, algorithm, issuer and various other info which can be used to validate it. I have also seen API providers who provide both the access_token and id_token and as far as I know it is for backward compatibility.
My question is that is it possible to use both the access_token and the id_token for accessing the protected resources ? Or is the id_token just for verification purposes and access_token is used for getting access to protected resources ?
Originally, OAuth and OpenId are designed for different purpose: OpenId for authentication and OAuth for authorization. OpenId Connect is a unification of the two and serves for both, but does not change their original functionalities. Keeping that in mind, you should be able to find out yourself. ;-)
The id_token is used to identify the authenticated user, e.g. for SSO. The access_token must be used to prove access rights to protected resources, e.g. for the userinfo endpoint in OpenId Connect.
Another angle to provide an answer:
id_token
An id_token is a JWT - make note of that!
It contains claims about the identity of the user/resource owner
Having a valid id_token means that the user is authenticated
access_token
An access_token is a bearer token
A bearer token means that the bearer can access the resource without further identification
An access_token can be a JWT (see Appendix point 1.) or opaque
If you want to read more: Types of tokens in oidc and oauth
access_token is useful to call certain APIs in Auth0 (e.g. /userinfo) or an API you define in Auth0.
id_token is a JWT and represents the logged in user. It is often used by your app.
is it possible to use both the access_token and the id_token for
accessing the protected resources ?
Not completely, first, you need to use id_token to log in,
second, you will get a accessToken,
last, use accessToken to access data.
Here is an article that describes why the id_token was introduced and what was it's initial purpose: Why we need a id_token in OpenID Connect & Facebook Connect. In short they tried to standardize the Hybrid Flow that was used by the Facebook.
We considered was using the id_token as the access_token.
We rejected that option because:
Many providers have existing OAuth token formats for there endpoints that wo uld be difficult to change.
We don't want long term access tokens being stored in the browser as cookies.
There are clearly separate recipients of the two tokens overloading the semantics of the two tokens would reduce flexibility and increase complexity in the long term.