I'm using identity server to protect my apis, to access the backend resources, a client must request a token based on user credentials and pass them to the next apis to consume them. My question is, how do I protect my registration apis when there is no user yet and hence no credentials to generate a user token? here's my thinking process:
Option 1: apply rate limit on my signup apis to limit brute forcing and api abuse:
Problem: the users of my app live in worker camps where they share the same wifi and the rate of calls from one ip being high is a reality.
Option 2: use captcha
Problem: my user base is not familiar with captchas (for certain reasons) and business conversion would be hurt by using captchas.
Option 3: Use OAuth2 with client id and secret to protect those particular apis:
Concern: I might be wrong but I think such authentication is best used between two systems, as someone can sniff the network and get those client ids and secrets and comprise the apis.
What do you think is a good solution to this?
It is a good idea to implement both recaptcha as well as API rate limiting. Recaptcha will prevent the bot attack and API rate limiting will prevent the Denial of Service attack.
Latest version of google recaptcha do not need the user to enter text in the textbox.
Related
I'm developing the authentication/authorization architecture for several APIs.
I'm using IdentityServer4 as a Security Token Service (STS).
From what I've read from "Dominick Baier" (one of the persons that built IdentitySever4), there are only two types of Flows that should be used:
Client Credentials Flow. (machine-to-machine)
Authorization Code Flow + PCKE. (for iteractive users).
I have several C# Web API's that will communicate with each (Machine-To-Machine), and I will use the Client Credentials Flow.
But then there are some WPF Desktop Applications, that will need to access some APIs, and don't have a user.
Which flow should be used?
I've read that:
Desktop/Native & Mobile Applications should use Authorization with Authorization Code Flow (with Public Client and PKCE), since they are hosted on the Client side, and the Client/Secret is can be leaked (maybe on a Desktop application we can Encrypt the Secret? But then will need to manage a way how to store the secret that decrypts that right?)
Then I've read:
"Anytime you have a system that isn’t concerned with the end-user identity (and just needs to authenticate the system), use the OAuth2 Client Credential Grant."
For now, this is my case, I'm not concerned with the end-user identity (but maybe in a near future I will).
So since the above points conflict with each other:
- Which flow should I use?
- Can I have a Desktop Client using Clients Credential Flow and be safe?
Also, I've read a bit about Mutual TLS, If I use that, does this change which flow should I use?
You can't trust a client because you can't be sure a request originates from the client. And another problem is that clients are not good in keeping secrets. But there are different types of clients.
Clients that run on servers often having a single task, like synchronizing data which is user independent, are suitable to use the client credentials flow. To some degree they can keep a secret (running on a server).
You can use unique credentials for each instance but that doesn't make it safer. It helps you to identify the client, but doesn't add security. Security is about monitoring behaviour and detecting anomalies. Or perhaps narrowing access by filtering on ip address.
But you are not limited to use the two flows you've mentioned. Being a token provider, you can extend IdentityServer with custom flows using extension grants.
Without user the client credentials are somewhat similar to the resource owner password credentials (ROPC) flow (another option that is no longer covered in the grant type documentation but still exists, see the old docs). Neither are really safe in the sense that both can be automated. The user factor can be eliminated since user interaction isn't required for these flows.
But I wonder why your app has no user, running on a user machine. Because ideally you have a client (without secret) where the user logs in and let the client contact the api (delegation).
So there are two things: do you need to identify the client? If not you could suffice with an ApiKey, like e.g. Sendgrid. And you can never trust a client. Security has to be server side.
So basically it doesn't really matter, there is nothing you can do to make it much safer client side. The only thing you can do is add the requirement of user interaction. So perhaps now you don't need it, but it will increase security and allows you to delegate api access to the client.
I'm developing a social network. I have a RESTful API coded in C# and my front end application on objective C. My architecture is very simple:
Iphone Users (mobile app) < - > RESTful API < - > DATABASE
I want to implement authentication for my service and to make is secure. Also i want to be able to retain something in the phone that tells if it is logged or not and with which account.
I've been reading and i found out that oauth is standard for this. i have a lot of questions that i don't understand. There is suppose to be a previously shared between the resource owner and the server.... who's the resource owner in this case? the user itself? and i imagine the server is the RESTful API. About the security token, is it coded in the mobile app? and in the server?
About the token. does the token retain information about my login? I mean, is the token what tells me what user I am while I use the app? this is what differences two users when they ask for example GetMyFriends ?
and for last, whats an API Key and how do I implement it and use it?
thanks.
This question will require a book volume to provide every possible answer, so I'll try to answer a small bit of questions I can and hopefully that will direct you on the right track.
1) How do I make my client-server connection secure?
Use SSL certificate for the HTTP server that hosts your API.
2) How do I implement my authentication and keep track of which user is currently active in the system?
There are numerous ways to implement your own authentication and I'll only provide a short description. Use two instances of UITextField to get user's username (or e-mail) and password. Send those values to your REST API. To keep track of a currently active User you'll either nee to implement a fairly complex solution using CoreData, where you would create a User entity and have something like an "isActive" boolean value that you'll set to YES once a given user logs in. Keeping it a bit simpler you can just store an NSDictionary representation of your active user's parameters you get from server after authentication.
3) Is oAuth standard for this?
No, do not use oAuth for your own application. You only need to use oAuth to provide third-party applications an ability to log in users into your web application. xAuth is standard - request authentication credentials from user via UI in an application and send those credentials via your API to server and process the response.
4) About the token. does the token retain information about my login? i mean, is the token what tells me what user i am while i use the app? this is what differences two users when they ask for example GetMyFriends ?
Answer #2 should answer how do you know which user sends request. You can retain an information about the currently active user by setting the values you're interested in in the current session, for example - user_id, so you can distinguish which user sends the GetMyFriends request.
I know this doesn't even remotely covers the whole area of what you're asking about, but you need to do a bit better research on this topic.
What are the best practice for implementing authentication for REST apis?
Using BASIC auth + SSL or something like https://datatracker.ietf.org/doc/html/draft-hammer-http-token-auth-01?
Are there any existing solutions available (for .NET / WebApi)?
The answer on this depends on the audience for your Web API and what you want to authenticate exactly.
Do you want to authenticate a client application that uses your Api?
Do you want to authenticate a user from your application to retrieve their data within a client application (using your Api)?
Or do you want to authenticate both the client application and the user using the client application.
Depending on what you want to authenticate you have multiple options. But always keep in mind that it is better to go with a solid solution where many client libraries are available than reinvent you own. Never do a little off this, but in your own way, chose one way of authentication, stick to it and don't break the client libraries.
Basic authentication: Is very easy to implement, but you authenticate a client app with it, not a user. This kind of authentication is nice when business trust relation needed and authentication and safety is not your very first concern. But there is no way to track a call in your API back to a certain user, just a client application. Of course you could save your user's username and password in a client application but this is a bad practice in more then a single way.
Token based authentication: Their are many ways of token authentication but the one i'm talking about here is a single token for a user which the user copies to the client application to get access to your Api. This way you can authenticate a user (who made this call in my Api?) And it is fairly easy to make and use. The withdrawal is that it is not the most secure way, requires user interaction and that a user possibly uses his Api token in more then one application. You could extend this way of authentication with basic authentication to authenticate a client. So a clientid + clientsecret + token to identify the user. But I think if you want to accomplish this it would be better to take a look at Oauth2.
OAuth2: If you want to have full access over your authentication you can go this way. It is possibly the most future proof way to go, but also requires the most work (at least at the identity provider/resource provider side. The client application has a fairly easy time implementing this with a lot available client libraries. If you go with this way of authentication (also token based) you can authenticate the client and the user, without the need to share your users username and password.
My recommendation: would be to go with Basic Authentication if this fits your case, it is easy and together with HTTPS is fairly safe. If it doesn't fit I would go with Oauth2 because it is the most solid and used standard (Instagram/Google/Facebook), gives you a lot off freedom and with a growing ecosystem gets easier and easier to implement. After all for someone implementing your API it is way more interesting to learn something about Oauth 2.0, then learn about the jgauffin way of doing things.
Reference: I would also like to invite you to have a look at Apigee's website. Api's are their business and they have quite some interesting reads. One of them is is a free ebook - Oauth the big picture which also has a interesting paragraph where they ask if you really need Oauth. (From page 16 - Is OAuth all you need for API security?)
For server-to-server APIs - APIs designed to be used only by a small number of servers –
OAuth is overkill. Having a separate set of authentication credentials for each app is a nice
feature of OAuth, but for server-to-server use, the need to log in securely using a browser,
or to implement other steps in the OAuth “dance,” gets in the way.
Instead, using a simple security standard like HTTP Basic authentication and assigning a
unique password to each app is sufficient. Two-way SSL is another good, albeit
cumbersome approach that has the advantage of stronger, more traceable authentication.
However, think ahead! Are those APIs really only going to be used by servers forever?
Exisisting Solutions: Whatever way you go leastprivilege - Dominick Baier and his nuget packages can give you a nice headstart. Implementing basic authentication using his Identitymodel is really easy. Also if you want a ready-to-go identityserver to provide you with tokens look at his identity server which does all you can think off. However if you decide to go for Oauth2 I would also have a look at DotnetOpenAuth since it is (imho) a bit more configurable and easier to tweak to your own like, but it also takes more work.
You should look into Security Token Service or STS.
Check out these links for more information:
Off-the-shelf Security Token Service (STS) that uses ASP.NET membership provider?
http://msdn.microsoft.com/en-us/library/ee517259.aspx
You could have a look here, IdentityModel has Web API support:
http://thinktecture.github.com/Thinktecture.IdentityModel.45/
We have an application which we need to allow users from our customer's systems to be able to sign in without seeing another log in screen.
What is the best way to provide an SSO type experience for our customers? I have tried to research Azure ACS and Windows Identity Framework but they all seem to be based on this idea of a common log in popup/screen which all sites use. Unless there is another aspect to this federated identity system I don't think that will work for us. Basically our customers are education institution which have students who sign in and use their own web applications/portals. These customers purchase access to our application and want their students to be able to click a link from their portal and automatically sign into our system.
From looking around it seems important to know that these systems are running on completely separate domains. For some legacy systems we have asked our customer to provide simple api endpoints for a very custom sso implementation. What I'm looking for is any information about a more standard approach for SSO.
SAML 2.0 is the standard for single-signon. Your clients would need to have some authentication mechanism on their sites that can be translated into a SAML call to your application.
When they sign the student on, they should make a quick call to your application, passing you the username of whoever is logged in. In return, you generate a token, store it in a DB along with the username, and send them the token. They append that token to any link to your app in GET form, and it "uses up" the token (removes it from the DB) but signs them in to that account.
Upon generating the token, you can also remove one "credit" from that applications allowed requests, or whatever else you want to do there.
Our specific needs required us to roll our own SSO type system using some simple secret token handshakes.
I have an application that I've developed in .NET 4.0/C#. It's designed to be used by customers that want to watch hardware sensors and alert them of specific values. One option for notification is by "tweeting" to a Twitter account of their choice. Before Twitter changed to OAuth, users entered their account name and password and this was enough to send Tweets on their behalf.
After reading up on the Twitter API and OAuth, I want to see if I understand correctly the best way to maintain this functionality.
I've registered my application with dev.twitter.com and obtained the necessary Consumer Key and Consumer Secret.
The application may potentially need to tweet to more than one Twitter account as it is used by multiple users per installation.
If I understand things correctly I will need to do the following:
Provide some sort of "Request Authorization" button on a per-user basis, which launches a Twitter authentication web site. There, the user logs in and is then provided with a PIN number.
Use the PIN number to obtain the user's AccessToken and AccessTokenSecret.
Store both of these tokens between sessions (launches) of the application.
My questions:
Should I encrypt either of these tokens when storing (in SQL)?
Is it ever necessary to re-authorize? The program is intended to be setup just once, then run unattended. Re-authorizing accounts will be a deal-breaker.
Though it shouldn't affect any answers or advice, I am using the TweetSharp library.
Your understanding seems pretty good to me.
It depends on how you store your consumer key and secret. If an attacker could gain those and the user's tokens, then that would be bad. The tokens aren't much use without your tokens too.
Only if the user revokes their authorisation.