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.
Related
This is my first question on the Stackoverflow. I have already read the https://stackoverflow.com/help/how-to-ask section and I have read and read and read over the internet to find the connection between OAuth2 and MFA. Which made me more confused. When I take them separately I understand the basic concept.
Background. I am developing a windows application and using mailkit to implement the email there. When I research how to implement MFA on that, most of the answers are talking about OAuth2. That's why I really need to find an answer for this questions.
I have read
https://learn.microsoft.com/en-us/answers/questions/513048/microsoft-office-365-outlook-sending-emails-using.html and https://github.com/jstedfast/MailKit/blob/master/ExchangeOAuth2.md and many more articles to achieve my goal. They all are talking about OAuth2 not MFA.
I am sorry if my questions doesn't make much sense. Please help me to understand this.
Thank you.
OAuth 2.0 and MFA are not related to one another directly.
OAuth 2.0 is an authorization protocol which provides a client application with the delegated access. Way of delegation is defined by grant type and based on the use case you can choose one or another. It does not tell you directly how to authenticate the end user.
For example, using classic authorization code flow you can point the user to login page and optionally consent screen (allow / deny access to the app). An example of URL would be:
https://authorization-server.com/auth?response_type=code&client_id=CLIENT_ID&redirect_uri=REDIRECT_URI&scope=photos&state=1234zyx
Then it's up to authorization server how to authenticate the end user. It can be a login / password screen followed by any type of MFA.
MFA, on the other hand, stands for multi-factor authentication, meaning that there can be 2 of more factors of authentication (such as login and password pair followed by one time code, SMS or anything else).
Based on my understanding of the OAuth2 with Exchange that you've shared, you just need to register an application on Microsoft platform in order to access Microsoft APIs for email sending. That's indeed an OAuth 2.0, but I don't see anything related to MFA there.
While developing an on-premise, intranet-only REST API server for my company, I managed to completely confuse myself regarding authentication issues.
I have:
A REST web server implemented in C#, using self-hosted Nancy, running as a Windows Service
A C# client that can query the server, run by a user in our company
I do not have:
Any form of access to our Active Directory and/or domain controller, apart from what any application running under Windows normally has
Any way to influence AD settings or configuration
Active Directory Federation Services (ADFS) (I think. We use Windows 7 and Office 2010, just to give some perspective on the state of the software landscape)
Azure Active Directory (AAD)
I want:
A way for the server to authenticate that a request is made by a user of our company
It is perfectly fine if the client has to sent some additional authentication data with each request, as long as it does not contain the user's password in any form
I do not want to:
Have to set up any additional software (my server must be minimum configuration and maintenance, so the average user can install and run it)
Install / configure / maintain an IIS server (see above)
Use ASP.net (way too big for my needs, plus see above point(s))
Handle user passwords in any way (company policy and common sense)
Impersonate the user (I only need to validate the authenticity of the request)
Implement my own user account database. We already have half a dozen services that need their own username/password combinations, I do not want to add yet another one
I have read articles that show how to use Windows authentication with IIS, or how to use Azure Active Directory (AAD) with Nancy. Other questions here have already informed me how to authenticate username / password combinations against the Active Directory. However, none of these satisfy all of my requirements or have requirements of their own (like AAD/ADFS) that I cannot meet.
It seems that Kerberos/SSPI might be what I want, but it seems very involved and quite complicated to get working with C#. It is possible I will have to go this route, but I could really benefit from some minimal working example (the accepted answer provides a C# implementation/wrapper, including an example project, but I can't seem to be able to make heads or tails of it).
Maybe I am naive, but what I image the solution to be is something along the following lines:
The client queries a service (AD, Domain controller, ...?) for some form of authentication token, using the credentials of the currently logged in user
The token is then sent to the server together with the username, as part of the request that needs to be authenticated
The server extracts the token, and queries the same service (AD, Domain controller, ...) whether the token is authentic, valid and belongs to the user in question
Is this possible at all? Ideally, with some sort of ready made library that I can plug in to my projects (I'm reaching, I know)?
You can do this with stateless authentication and Jwt. Send a username and password to "/ auth" (example) and "/ auth" will search the AD (example) and validate if the user exists, then create a Jwt token with the name of the user on load. When you make a request, you will only send a Jwt token and Nancy validates the token.
I have an Azure account and currently a Mobile Service setup with a SQL Database so that my Windows Store app can communicate with the database.
I have developed sites using ASP.NET WebPages authentication. And I need something similar for my Windows Store app.
I have successfully gone through the documentation and tutorials on the Windows Azure website and implemented ACS (Windows Live ID, Google, Yahoo!, and Facebook) - but the thing is - I don't want Google, Yahoo!, Facebook or even Windows Live ID or Microsoft Account) logins - I want my OWN login but it seems that they don't give you this option (correct me if I am wrong).
I need to allow users to signup from within my application (that means, providing their name, DOB, email, phone, address, etc) and shove it all in my database.
Now, after implementing Microsoft Account login with my Azure service, I found out that you can't even get the most basic information about any user who has logged in to your application - not even an email address.
I have spent hours searching online for something that could possibly help but I am running out of keywords - and have not hit a single related result yet.
Does anyone know if this is possible? How would we go about integrating login and signup with a Windows Store app that set/gets this data into/from a Windows Azure service?
Any code, samples, links, tutorials, documentation, etc would be highly appreciated.
You have gone down the road of hooking up external identity authentication, which in my opinion for an external facing web application is a better approach. Benefits are:
Your application is only responsible for Authorization not Authentication. There is a whole lot of work involved in Authentication and a large number of best practices. Best let those who know best take the burden of this. This doesn't mean you shouldn't try and understand it though.
If your site gets hacked you don't have to tell them that their username / email and password combo has been compromised and they will probably have to change there passwords on other sits.
You are also making sure that your users don't have to remember / manage yet another username / email address password combo
If you really want to do the Authentication then that is fine but you will need to do it yourself. Have a look at examples on Asp.Net Membership. This is not the only way and nor is it the best way but there are lots of examples.
Now if you decide you want to use external authentication I can give you some pointers to help with your current implementation.
First thing to note that the Id you get back from Live, Google, Facebook can only be assumed to be unique for that provider. Therefore if you want to keep a profile in your system for that identity and you want to use more than one provider you will need to implement it in such a way that you can keep the id unique in your system and help you associate it with a provider.
Website Authentication with Social Identity Providers and ACS Part 2 – Integrating ACS with the Universal Profile Provider
As you have found out not all of the Authentication providers return the same "claims". A claim is something that user claims to have, such as an email address, name, date of birth, etc. All the ones you can use by default via the ACS return Uid and some return a name and email address. What you have to do is fill in the gaps. When someone registers you will need to pull the relevant claims and then ask them to fill in the missing ones. You may also want to map the different claims in the ACS to a common name that you can use in your app as one provider might use slightly different names.
Federated Identity with Windows Azure Access Control Service
Just because you do not handle Authentication you still need to be responsible for keeping your application secure. Half of the work has been done for you so your code should be a lot lighter but you will still need to make use of roles.
Windows Azure Role Based authentication (ACS)
The really nice thing about this approach is you can implement your application the same why SO have done with there identity model. You can allow users to associate multiple identities against their profile meaning they can login how they want to.
If you choose not to use the built in providers for ACS you will need to implement your own Identity Provider using SAML, OpenId, etc...
You can look into the Windows Identity Foundation (WIF) for implementing WS-Trust or WS-Federation.
There is also ADFS which has the same set of support but uses Active Directory with WIF and Azure has its own version of AD that can be used.
There is also thinktecture identityserver which can jumpstart your venture into IdP land, but I have not used it myself yet.
If you want to go the OpenId route there is DotNetOpenAuth.
If you're looking to add custom identity to your Mobile Services app, check out Josh's post on custom auth: http://www.thejoyofcode.com/Exploring_custom_identity_in_Mobile_Services_Day_12_.aspx
For the past 2 years we have created 3 desktop application and 2 admin section(web) for one of my client.
Every application uses its own authentication process.
I have merged the authentication process for web in single unit.
But the client wants to have one screen for getting authenticated on desktop application as well as on website.
he also want to use different browser and the username /password should be asked only once irrespective of browser opend.
I tried to use cookies for web. but every browser has got its own cookies.
Can any one suggest how can i authenticate a user for the whole computer so that authentication information is available to desktop application as well as to website irrespective of the browser being used?
Edit: As suggested by joe using windows authentication is not possible in my case.
So i created one more table with following column
ip,userid,authenticatedat
when ever a user is authenticated i insert its ip,userid, and time in table.
when ever a non authenticate user comes first i look in the table if the ip is present and authenticatedat is within 30 min i assume user is authenticated and set the session/variable with data required.
This i have checked and found it is working .
I have found this is not secure.
Windows authentication is the only way I know of doing this. Assuming your users are on a domain you control, then their Windows credentials would validate them, and they wouldn't ever need to enter a username and password.
Outside of that, I can only think of hacky dirty methods of making this happen. You could install a single authentication service on their machine which is available to connect to remotely from other applications - those apps would call your service, and that service would authenticate the user and pass an authentication token back. Easy enough for Windows apps, but making that work on a web app wouldn't be fun. Your web server wouldn't be able to talk to this service, so you'd have to rely on the client javascript talking to the service and retrieving a token or hash, and then the javascript passing this on to the web server.
Anything you put on a local machine, you have to assume the user can reverse engineer and manipulate, so if you need real security, I doubt you'll find a solution. Best bet is just to make the user log in every time you need to, and have your authentication/authorization code on your web service layer.
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.