Following the doco of JIRA REST API, OAuth and HTTP Basic are two recommended authentication. We are using the HTTP Basic one with https, which works good and safe.
Is there any difference on performance between them?
Excluding initial token negotiation, OAuth is still computationally more expensive than Basic Authentication, given the larger size of the secured payload, and the signing requirements. A non-exhaustive list of extra logic that needs to be carried out:
Request parameter normalization
Request URI normalization
Generate nonce
Request signature calculation
Reverse entire process on the receiving end
Compared with basic authentication which requires a very simple hashing in order to calculate the single required header - OAuth is without a doubt a more expensive authentication. But, the important thing to realize is that the two authentication mechanisms serve entirely different purposes. Basic Auth is for authenticating a client to a primary application. OAuth is for authorizing a third party to access client data from a primary application. Both have their place and selecting one over the other should be driven by the particular use case of the implementation.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 2 years ago.
Improve this question
i am developing an application with Angular Frontend and Java/Spring-Backend. For logging into our backend we are using Oauth2 Authorization Code Flow with PKCE and Open ID Connect.
When the user navigates to a protected route he is redirected to his IDP and has to login. After that he is returned to a redirect_uri with the authorization_code as URL parameter. So far everything is clear.
Now I am not sure what the best way to exchange this code for the access_token is? So far I've done this on the client (in JavaScript) and used the received JWT for further backend calls (on the backend I just verify the signature) and that does seem to work. But in other projects I've seen that colleagues actually used the backend kind of like a proxy. So they send the authorization_code to the Java-backend and the backend does the exchange.
Now I've read a lot, but can't seem to grasp the full implications of that. It does seem to me that it's safer to have the client/frontend do this. But on the other hand the backend is actually trusted, so we could actually use a client_secret in this case.
The question now is: Are both cases considered safe? Or is one considered more secure and if so: why?
Thanks in advance
*Edit: Just to clarify - we don't really need to access another resource server, the use case is that we just want to be safely authenticated to our own backend - once authenticated we switch to a session cookie anyway, so we don't store the access_token anywhere at all
Keeping the tokens in the backend is always a more secure approach because it reduces the attack surface and makes the code in the client much simpler.
A good starting point is to take a look at this BCP
OAuth 2.0 for Browser-Based Apps (section 6.2)
Another reference is:
Cheat Sheet: OAuth for Browser-Based Applications (e.g. a JavaScript SPA)
To make your JavaScript simple, I would do all the client authentication in the backend and when the backend gets the token, then create the session with your client. In that way the JavaScript client does not need to touch any tokens. Your internal resources/API would be accessed through the service that is responsible for the session. Clean and simple! :-)
yes! I think the classic mistake is to let JavaScript touch your tokens. You will sleep much better at night knowing that the tokens are only handled in the backend. Also, less security complexity and things you must master and understand! We must fight complexity!
The actual authorization code can only be used once so it doesn't matter if it is sent from front end or back end.
There are two common models here:
OPTION 1: WEB BACK END / PROXY PATTERN
This is used if you want to keep tokens out of the browser and use HTTP only cookies as a back end credential instead:
Web back end issues a same domain HTTP only cookie and stores tokens in either a database or the cookie itself
Web UI makes all API calls by first calling the web back end with the cookie
Web back end then looks up tokens and forwards them to the API
You need to deal with web threats such as CSRF and XSS
Challenges are:
More complexity than you'd like
Some architecture limitations
OPTION 2: SPA PATTERN
This is the cross domain model you are using and is technically simpler up to a point::
Web UI makes API calls by sending an access token
You need to deal with threats such as XSS and focus in particular on ensuring that use of tokens in the browser is no less secure than use of cookies
You need to store tokens in a secure manner in the browser, such as in memory
Challenges are:
If you have gaps in your security they will be easier to exploit since users can more easily see their own tokens
Token renewal and cross tab navigation aspects are trickier in this model.
FACTORS
These are the main factors when making a choice:
Security threat model - tokens v cookies and other factors
Wider architecture goals for Web UIs
Perception of stakeholders is often the single biggest consideration
Whatever you decide I would recommend starting with requirements rather than a particular technology stack.
RESOURCES OF MINE
I prefer option 2 since I think the architectural options are far better, but it requires care. The following links hopefully help you understand how I reasoned out my preferred solution:
Web Architecture Goals
Threat Model - Cookies v Tokens
End State and Cloud Deployment
Not everyone agrees with me though. Sometimes in software there are multiple solutions. What is important is that security threats are covered. You can potentially do that with either solution.
When your are called token from your client it's not the authorization flow it's implicit flow, and it's could be used when you don't have backend, and when you have backend you always should use authorization code flow as you've mentioned. You can learn more about openid flows here.
Authorization code flow is considering more secured because it use backchannel communication(server to server) with idp for receiving tokens, while implicit flow send request from browser.
Sending client calls with PKCE is new technology and it's considered as safe but definitely authorization code flow is better choice for backend.
Introduction
So in my developer team, we need two server-based applications one located in my company architecture let's call it company server (i.e. resource and authorization server in OAuth2 terminology) and the second one in customer architecture let's call it customer server (i.e client and resource owner). The customer server is loading data from the company server so my company server needs to authenticate it somehow.
My team decides to apply OAuth2 standard with authorization and resource server in a single monolith application, without even thinking of benefits. This would, of course, take more time to implement than a simple constant key stored in the header. So I wonder what are benefits of that solution.
I know that Basic Authentication needs user:password base64-encoded in every request but the customer server is a single user so token would be in fact constant key stored in the header and I will use that terminology in terms of simplicity.
Argument - Microservices
In M2M (machine-to-machine) communication according to this article, customer server should obtain the token by providing client_id and client_secret from authorization server then you can use with multiple resource servers. The first argument I see is that OAuth2 pattern allows us to use multiple resource servers without additionally reimplementing authorization in each of them (because token is JWT or resource server is checking token against authorization) but in our case we have only one monolithic company server that is responsible for being resource and authorization so I see no benefits of that.
Argument - Man-in-the-middle protection
The other argument of using OAuth2 is protection against man-in-the-middle attack if someone intercepts token. The authorization server can invalidate token (directly in storage or in case of signed JWT by short expiry time) and prevent using compromised token. But...
Connection between servers is SSL secured
There's no way to steal token from storage like in a web-based or mobile-based application because key is located on the server-side itself.
Summary
So I can't think of any security benefits using OAuth2 compared to using the constant key in every request in this situation.
Security is mostly a chicken-egg problem. You encrypt secrets with encryption key and then again you think how do we handle the encryption key in a secured way. Don't assume here that TLS/SSL is infallible. But the core objective has always been to reduce the attack surface and make it more difficult for malicious users to break the system.
Even when there is no "Man in the Middle", when you send the password with every request, both the receiving side and the sending side keep the password in memory. It leaves more opportunity for an attacker to get hold of the password. A simple memory dump can expose the password.
In case of tokens, you don't always need the private key in memory to verify the token signature. You can cache the valid tokens at the server end and simply do a string match. Or you can use a public private key pair.
So, it's okay not to use OAuth2, if the security requirements are not stringent enough to justify the development effort required for a more secured solution. But it is better to use proven best practices and solutions.
We need to expose a REST endpoint to the outside world to be called by an external service which we don't control. The people responsible for this external service seem to be security experts (not), and so instead of using at the very least HTTP Basic Auth or any other real authentication mechanism, they authenticate themselves using a fixed secret. It goes like this:
GET /endpoint?secret=WE_ARE_THE_TRUE_GUYS
As we're already using spring-security-oauth2, we'd like to integrate this authentication flow with our existing flow so that we can specify rules for this endpoint the same way we do for every other enpoint on our ResourceServer, get the same error handling behaviour and etc. How shall we go about implementing a custom authentication filter - or whatever it may be - that will grab the secret parameter from the query string, transform it into some kind of "client credentials" for a pre-configured client on the AuthorizationServer and integrate seamlessly with the rest of the OAuth2 flow?
If you can transform "WE_ARE_THE_TRUE_GUYS" into a valid OAuth2Authentication then all you need is an authentication filter that does that (and sticks it in the SecurityContext). Then the downstream filters and handlers will behave just as if it was a real OAuth2 authentication. If I were you I would put some very tight conditions in that filter to match the request to one that is on the allowed resources from this highly unusual and not very secure authentication channel.
I'm starting a new system creating using .NET MVC - which is a relatively large scale business management platform. There's some indication that we'll open the platform to public once it is released and pass the market test.
We will be using ExtJs for the front-end which leads us to implement most data mining work return in JSON format - this makes me think whether I should learn the OAuth right now and try to embed the OAuth concept right from the beginning?
Basically the platform we want to create will initially fully implemented internally with a widget system; our boss is thinking to learn from Twitter to build just a core database and spread out all different features into other modules that can be integrated into the platform. To secure that in the beginning I proposed intranet implementation which is safer without much authentication required; however they think it will be once-for-all efforts if we can get a good implementation like OAuth into the platform as we start? (We are team of 6 and none of us know much about OAuth in fact!)
I don't know much about OAuth, so if it's worth to implement at the beginning of our system, I'll have to take a look and have my vote next week for OAuth in our meeting. This may effect how we gonna implement the whole web service thing, so may I ask anyone who's done large-scale web service /application before give some thoughts and advice for me?
Thanks.
OAuth 1 is nice if you want to use HTTP connections. If you can simply enforce HTTPS connections for all users, you might want to use OAuth 2, which is hardly more than a shared token between the client and server that's sent for each single request, plus a pre-defined way to get permission from the user via a web interface.
If you have to accept plain HTTP as well, OAuth 1 is really nice. It protects against replay attacks, packet injection or modification, uses a shared secret instead of shared token, etc. It is, however, a bit harder to implement than OAuth 2.
OAuth 2 is mostly about how to exchange username/password combinations for an access token, while OAuth 1 is mostly about how make semi-secure requests to a server over an unencrypted connection. If you don't need any of that, don't use OAuth. In many cases, Basic HTTP Authentication via HTTPS will do just fine.
OAuth is a standard for authentication and authorization. You can read about it in many places and learn; Generally the standard lets a client register in the authentication server, and then whenever this client attempts to access a protected resource, he is directed to the auth-server to get a token (first he gets a code, then he exchanges it with a token). But this is only generally, there are tons of details and options here...
Basically, one needs a good reason to use oAuth. If a simpler authentication mechanism is good for you - go for it.
I am building a RESTFul API and wondering what's the best way to do auth? Users will need to authenticate. I know of three ways:
1.) Pass API key in every RESTFul requests:
http://api.mydomain.com/api-key-here/get-users
This is nice because developers can immediately start using the API by simply copying URL string into the browser. Are there any potential security risks though?
2.) Every request passes the API key in the header of the request.
This seems to be more secure, but developers can't make requests via their browser. CURL is required.
3.) oAuth
I must admit I don't know much about it, but seems very popular. My concern is that its a barrier for developers to start using the API. They first must be familiar with oAuth, and have it setup.
Thoughts? Thanks greatly.
If your concern is burdening developers with a high cost to entry, I suggest basic auth, but running your API over https.
I do this with Diligent Street and it works really well. I use an API Key and couple it with a Secret as the username/password combination for basic auth.
I have employed the technique found here: Build a RESTful API. This solution uses an MD5 hash of your API ID, API secret and the UNIX Time stamp and passed in the HTTP header. This authentication method is the same used by Mashery’s Authentication.
This link references and contains a full blown starter kit for creating an API that has Auth, Membership and*API Usage Metering* along with a supporting EF database.
As for testing the service you can use RESTClient to execute HTTP calls with custom headers instead of using Curl.