I'm trying to write a script to update metadata on various datasets, using an authorized app. Using OAuth seems like the wrong approach (it's not a web-facing application for other users to use as themselves), and passing my own user name and password seems...icky.
The SODA API authentication documentation is pretty confusing:
All HTTP-basic-authenticated requests must be performed over a secure (https) connection, and should include an application token, which is obtained when you register your application. However, authentication [sic, should be "application"?] tokens are not strictly required when a request is authenticated. Authenticated requests made over an insecure connection will be denied.
Here is a sample HTTP session that uses HTTP Basic Authentication:
POST /resource/4tka-6guv.json HTTP/1.1
Host: soda.demo.socrata.com
Accept: */*
Authorization: Basic [REDACTED]
Content-Length: 253
Content-Type: application/json
X-App-Token: [REDACTED]
So:
Can you even use app token + secret token to authenticate with HTTP basic?
Which of the two "[REDACTED]" is the app token, and which is the secret token?
My guess (based on some testing) is that the answers are:
No
The first "[REDACTED]" is the Base64 version of username+password, the second one is the application token, which is not relevant to authentication.
Application tokens and secret tokens aren't actually tied to any sort of pre-baked user authentication. They're tied to your application, and are then used in OAuth to ensure that your app is what it claims to be when the user is passed through the OAuth workflow. Once the user authenticates, the app can retrieve an authentication token that is used to actually authenticate their requests.
What you're really looking for is a way to retrieve a "bearer token", which some API providers allow you to generate. This would allow you to basically "pre-OAuth" and get an authentication token without going through the full workflow. Unfortunately we're not one of them (yet) so you'll need to authenticate with plain old HTTP Basic and your username and password.
If you want a slightly-less-icky way to do that, I recommend registering a "bot" account that you grant only the necessary permissions on the necessary datasets. Then at least you're not baking your regular user credentials into your config. But keep in mind that even if we had bearer tokens, you'd be putting those into your config somewhere.
To answer your more specific questions:
No, because then one of them would have to be a bearer token, which they are not.
The Authorization header is the Base64 encoded username:password, while the X-App-Token is your application token. In this case the latter is just an extra header that would identify that request as having come from your app.
Thanks for your feedback on the docs - I'll clean them up and try to be more straightforward, and I'll definitely fix that typo.
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.
When protecting APIs using bearer token authorization:Is there a need to validate that the token was issued from my identity server or its already happening in the background and how do I do that?
What role do scopes play when it comes to bearer tokens?
In short, yes you need to validate that bearer tokens are issued by a issuer you trust. That means either by validating that it's signed by a trusted issuer, or making a API call to the isser you trust to ask it if it indeed is issued by the issuer you trust.
In practice: when talking about Katana, this is done by using a combination of [Authorize] filters/attributes and Owin middleware:
Option 1
The middleware from Microsoft:
app.UseOAuthBearerAuthentication(opts)
https://msdn.microsoft.com/en-us/library/owin.oauthbearerauthenticationextensions.useoauthbearerauthentication(v=vs.113).aspx
https://www.nuget.org/packages/Microsoft.Owin.Security.OAuth
Or, optionally, the middleware from Brock Allen og Dominic Baier:
Option 2
using the following abstraction that builts on top if Microsofts middleware (IF you need the extra features it provides):
app.UseIdentityServerBearerTokenAuthentication(opts)
Source: https://github.com/IdentityServer/IdentityServer3.AccessTokenValidation
NuGet: https://www.nuget.org/packages/IdentityServer3.AccessTokenValidation/
Scopes
When it comes to scopes & API access, scopes are something that represents the resources you want to protect. When a client asks for a access token, it can ask for a token to include a given scope. Your identityprovider then validates that this client is indeed allowed to receive a token with this scope. If successful, the end result is a token allowing the client to call a API using this token.
Since the API trusts token issued by this identityprovider (or token provider), all it has to do is to
Validate that that the token is issued by someone that API trusts
Check that the token contains the scope that represents it's resource
I created asp.net web api project. I need to add authorization or/and authentication. I've read a lot about OAuth, SAML, JWT, HMAC etc. and everytime I see author emphasizes that OAuth is not authentication and you need to differ authN from authZ. I'm a bit confusing because I don't understand:
when I need to use authentication (SSO, login/password) and when authorization(OAuth, tokens) for API?
are HMAC, JWT for authorization or for authentication? because they are signed and I can add userid to this token use like user identifier
what are real differences between authN workflow and authZ workflow?
OAuth can be also used to authenticate users using a resource owner grant (i.e. a client gets an access token providing an user+password credential).
The resulting access token is what you should call authorization, since it will contain info like claims describing permissions, permission masks or roles (it depends on what authorization scheme you implement in your solution).
A JWT (JSON Web Token) is just a JSON representation of both access token and any other associated info. JWT is the content of some authentication result which can be used to be authorized against some resources. Since the JWT contains an access token, if you're using basic authorization, you'll add an Authorization header to your requests: Authorization: Bearer [your access 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.