Lets assume i have REST api with products and i want it to be accessible only for specified users.
The list of users is known for me and i'm looking for some way to give them safe access to my API.
I don't want to create authentication with username and password, generate token and this stuff.
What i can imagine is that i'm giving each of my users some secret string
and they use it in every request.
And what i need is some example/tutorial/name of this kind of solution,
i'm sure there are some standards for that but i don't know it.
I know it's kind of nooby question - sorry for that, i'm just asking ;).
Thanks in advance!!
You are looking for a simple shared-secret authentication. A simple solution in this case is just to check for the secret as a param (or it could be in the request header). For example, the client can call:
https://example.com/valuable-stuff?secret=2Hard2Gue$$
You implement this in your web request handler as:
SECRET = '2Hard2Gue$$'
function showValuableStuff() {
if (params['secret'] != SECRET)
return NotFounderError;
// now retrieve and output the resource
}
Some practical considerations are:
Use a secure connection for this to prevent the secret being leaked (ie a secure HTTPS exposure).
Be careful where you store the source code if you're hard-coding it. A fancier solution is use an environment variable which is set on the server, so you keep this out of the source code. Or at least to encrypt the part of the source that contains the secret.
While this is fine for simple solutions, it violates the basic security principle of accountability because you are sharing the secret with multiple people. You might want to consider allocating each individual their own random string, in which case, you may as well use HTTP Basic Authentication as it's well supported by Apache and other web servers, and still quite a lightweight approach.
Related
My task is to implement a resource server(RS) for IdentityServer4(IS4). The RS should fetch data from a database and send the necessary information as a json object back to the caller (client). This is needed because we have to return complex objects.
I already setup IS4 succesfully and its already running in Docker for testing purpose. I also setup the needed database.
My understanding of the flow would be, the user requests data from the RS sending the access-token, the RS then validates the token, checking if the caller is allowed to access the api using the IS4, if everything is okay the RS returns the data to the caller.
My problem is, as I'm new to this subject, how would I implement a RS? Do I create an API which is added as a scope to the user? Or is there a RS already implemented in IS4?
So yes you'll need to write your own API to serve your own resources, IdentityServer will only manage your identities for you (as well as handling external logins if that's what you need). I'd recommend going to the IdentityServer docs and working through the quick starts in order as shown below:
This will give you a good start but you'll then need to go away and research APIs more generally, there's a tonne of good info online about building (RESTful) APIs. You may find it useful to sign up to something like PluralSight and work through a couple of their courses, they're often very good.
One other thing to bear in mind is that IdentityServer is for identity, in other words Authentication and not specifically for Authorisation so you may need to add something for this. You can of course use a users identity for authorisation purposes but in most cases you'll probably need to augment the info you store about their identity to authorise them for access. See this link for more info around this topic.
I read many posts about passing sensible data in a GET request but didn't find an answer that would suit my needs.
I have to expose a RESTful resource that will check the password strength.
GET http://api.domain.com/security/password/P#55w0rd
I find the GET HTTP verb suitable since I only want if the password is secure enough.
The problem is that the client will be forced to pass it in the resource (i.e. URL).
Some colleagues told me to use POST and then pass it in the data body but I'm not sure how RESTful is it.
The REST standard just says to use HTTP Verbs. It doesn't actually mandate that you use particular ones. However some conventions have arisen about which verb to use, POST to create & GET to retrieve data, however this should not be followed religiously if it will cause an issue.
As per the following article you should not use GET for password, and yes you can use POST or pass something in the HTTP headers instead.
REST Security Cheat Sheet
Session management
RESTful web services should use session-based authentication, either by establishing a session token via a POST or by using an API key as a POST body argument or as a cookie. Usernames, passwords, session tokens, and API keys should not appear in the URL, as this can be captured in web server logs, which makes them intrinsically valuable.
I went with this:
GET /api/public/check-password
Authorization: Basic <base64(test:<password>)>
The username must literally be either '' (empty string) or 'test'.
I chose to use
test because it's obviously not a real user
GET because no modifications are made
The Authorization header because the security middleware in (most?) application stacks already removes that from logging - so no special care is needed.
/api/public because it doesn't require authentication to do the check
I'm not in love with check-password - that sounds more RPC-ish than REST-ish... but what can you do? At least it's obvious. I'm open to other suggestions.
I have some REST services on my site that will be available for 3rd parties to access.
My plan is simple. In order to call on these services, they need to request a key from me. I will privately supply them with a GUID. Each call to any of my services will, via a filter, check the header for the key and accept/reject the request accordingly.
This site is all HTTPS so the key would be encrypted during transit. I'm not worried about the key being visually identifiable to authorized clients. In other words, I'm not worried about any kind of 'inside' attacks or people sharing the key. I just don't want random, unauthorized outside users.
I have looked around and I don't really see anybody doing it exactly this way. I feel like I'm over-simplifying... but on the other hand, I don't see what's wrong with it either.
My question is.. does this sound secure enough (from a basic/minimal perspective) or does it expose some gaping security hole that I'm not seeing?
FWIW - I am using the Spring Framework, including Spring Security 4.
Thanks!
If it's HTTPS and the API key is in the header encrypted during transit as you described etc, then it follows a pretty standard design authentication pattern.
Your security now depends on how you distribute and store your API keys.
Although, you could use an "Application Identifier and Key pairs" approach.
Whereas the API Key Pattern combines the identity of the application
and the secret usage token in one token, this pattern separates the
two. Each application using the API issues an immutable initial
identifier known as the Application ID (App ID). The App ID is
constant and may or may not be secret. In addition each application
may have 1-n Application Keys (App_Keys). Each Key is associated
directly with the App_ID and should be treated as secret.
Just in case you wish to extend the application in the future.
I am at start of develoment of web-application. Application should be RESTful.
I am new to REST. And now I can't understand how user login/logout need to be done correctly to meet REST restrictions.
I spent good time to understand REST and already read many articles and answers on StackOverflow. Also I understand basic principle of "stateless" and it's benefits. So please no links on Wikipedia and basic sources about REST.
About task:
I have list of books in database on server. User who has login/password may come to site, enter login/password and view page with these books. So before to answer with list of books server need to be sure that user has rights to do it.
List of books will requested by AJAX call from browser.
I am going to make server to handle URL /books . When server receives GET request to this URL - it should
1) authenticate this call;
2) if OK - answer with list of books in JSON format.
As I understand so far - correct way of authentication for REST server is to authenticate each separate call. Client should use Secret Access Key and Access Key ID to encrypt query parameters. And server will check for Access Key ID, retrieve Secret Access Key (that is shared secret) and validate query in this way.
So server doesn't handle sessions because it violates "stateless" restriction of REST.
Only way how I see it could be done without sessions - use some Secret Access Key and Access Key ID to encrypt query parameters. This is how usual REST clients do. But there is a big difference between "normal" REST client and browser REST client.
Normal REST client (lets say it is standalone application or PHP-application on server) stores their Secret Access Key in some secure way. Nobody can see it. But JS application stores it right in code. And anybody can open this JS code and find this key.
So my question is:
How to organize authentication between browser (REST client) and server that handles REST API without exposing Secret Key to anybody who can open source code.
Or maybe I overestimate issue of storing of Secret Access Key in code?
I just see big difference with classical "stateful" application:
If I am logged in to some site and out of computer at the moment - nobody can come to computer and find my password in any place in memory of browser.
But with storing Secret Access Key in code it is possible.
Try to use the Basic authentication which works with browser based application. But problem with it is that it will always throw a pop-up to the user. An alternative to it is that you use a custom login header to do the authentication of each REST request, for example
headers : { "Authorization" : "customAuth" }
We intend to develop rest based api. I explored the topic but it seems, you can secure api when your client is an app (So there are many ways, public key - private key etc). What about websites / mobile website, if we are accessing rest based api in website which do not use any login for accessing contents ( login would be optional ) then how could we restrict other people from accessing rest based api ?
Does it make sense using Oauth2.0 ? I don't have clear idea of that.
More clear question could be ,How can we secure get or post request exposed over web for the website which doesn't use any login ?
If it's simple get request or post request , which will return you json data on specific input, now i have mobile website , who will access those data using get request or post request to fetch data. Well, some else can also access it , problem is i am not using Login, user can access data directly. But how can we restrict other people from accessing that data.
What do you think is the difference between securing a website that is not using REST vs one that is using REST API?
OAuth provides authorisation capabilities for your site, in a REST architecture this means a user of the mobile application will have to provide their credentials before being allowed to access the resource. The application can then decide on if that user has access to the requested resource. However you've said your website doesn't need use authorisation.
You can use certificates however good luck managing the certificate for each client. My take on it is for your explanation you don't need to secure your website because you will never be able to manage a trust relationship between the client and the server. There are some options though:
You build your own client application that you ship out to people which can verify itself with the server using a packaged certificate with the client. E.g. iOS has this kind of feature if you build for that device.
You provide a capability to download a certificate that is 'installed' in the browser and used when communicating to your REST API
Use something like a handshaking protocol so when a client wants to make the first request it says; 'hi I'm a client can we chat?' And the server responds with 'yes for the next X minutes we can however make sure you send me this key everytime you tell me something YYYYYY' (you can use something like SecureUDID or equivalent for other devices than iOS).
There are probably others but you get the basic idea. Again in my opinion if your resource doesn't need authorisation then you don't need to secure that REST API. Can I ask what kind of data are you exposing via this REST API or functionality your providing? That might help provide a better answer.
You want authorization: only some agents (mobile clients) and/or users should be allowed to access those APIs.
To solve that problem, you need identification: a way for the server to tell who is who (or what), so the right decision can be made.
There are many different way to provide some form of identification, depending how much you care about security.
The simplest is a user agent string, specific to your mobile clients. But it can be faked easily. Slightly harder to fake are client based 'secrets' - embed some kind of secret or key in your mobile client code. You can make it really complicated and secret, but as ramsinb pointed out, you can't get security this way as it would require you to be able to guarantee that the secret you're shipping with the client (wether it's code, algorithm or any other fancy construct) can't be compromised or reverse engineered. Not happening when you don't control the client.
From there, 3 choices:
Security isn't really required, don't bother
Security isn't really required, but you still want to limit access to your API to either legit users/agents or people ready to invest some time hacking your protection - go with a specific user agent or a client embedded secret - don't invest much into it as it won't block people who really want access to get it anyway
Security IS required - and then I don't think there is a way around authentication, wether it's login/password, user specific (device specific?) keys, OpenID, etc... No matter what, you'll have to add to the user burden to some extent, although you can limit that burden by allowing authentication to persist (cookies, storage....)