I am using angularjs on the client side and WEB API on the server side (C#).
I'm trying to implement Authentication and Authorization mechanizm,
I understand that session state is a "bad" practice for web api, so I read some more options, but somethings were unclear to me, or perhaps someone could suggest me a better solution, I would appreciate it.
after user logged in successfully, generate a token for him, and send it in the first response back to the client. the token will be added to any authorized request after that. the question is, how the server could tell what user is that? use DB to store data like username, and system role id, with the token as key?
after user logged in succesfully, encrypt or something like that important data like 'username;system_role;other_info' and send it back as a token?
perhaps use encrypted 'FormsAuthenticationTicket' of asp.net? like here?
I'm sorry for the long, and maybe too ease question, but I really couldn't understand from the web what is the 'best practice' for my case, and it is the first time that I don't use session for authentication.
thanks.
Related
First of all, I am sorry for my bad English.
I am writing an app with a backend, which I want to make safe. I am using HTTPS for the connection, but a lot of people say that this is not enough protection.
At the moment, my user credentials are sent to the server via JSON format as plain text, which isn't a good way, I guess. At the server, my password is hashed with a random salt and stored in the database.
If the login is successful, an authentication token is generated and sent to the client. The client is using it as a header.
Do I need to do more? I read something about digest access authentication. Should I implement this authentication method, or is there a better way to make my login safe? Or is this the right place to use this authentication method?
I have to start a new project to be developed in MVC 4 and Web API. I have prior experience with MVC 4 but with Web API this will be my first project. I understand that web api is there to be consumed by different platforms.
I have a few concerns related to web api. I am presenting them to you guys as following:
1) My first concern is related to user authentication. I looked into this SO question and followed the link1 and link2 given in the selected answer. I still have a couple of questions:
a) When we do user authentication through Form Authentication we create a cookie, that track if the user is authenticated or not, but with web api we do not store cookie, instead user credentials are passed in content header. I didn't get how user's logged in status is tracked in this case ?
b) My another concern is related to restrict unauthorized access, which I think I can find find out in link 1 and link2 provided above, if I am not wrong.
c) I looked at the Edward Brey answer (in the same SO question) as well for authentication but I didn't get the idea completely.
2) My second doubt is about mixing Form authentication and Basic Http authentication. Is it possible that for login I use forms authentication and then for consuming web api I use basic http authentication? If yes then please guide me.
My questions may sound inappropriate but please bear with me
1.a) Restful APIs are stateless, so you are not keeping track of user's logged in status, rather you are sending credentials which are verified for each of the requests
1.b) Yes, if not there are number of articles on web for that. Authorization Filters can help you in achieving this.
1.c) In short, he has mentioned simple logic to authorize user before executing any of the methods in your API. Call EnsureAuthenticated before executing any of the methods in a controller, or put that logic in you Authorize filter.
2) Yes you can do it. In Restful API's each call can be a new instance and you can pass in credentials with api requests whichever you are making.
If you go in discussion of Link 1 that you have provided, you will see:
In our specific case, the server generates the auth token by encoding
the concatenated username and password as Base64 (the reverse of what
is described in the article) and sending it back to the client via a
HTTP header when it performs their ‘log in’ action. The clients then
store this auth token and send it with each subsequent request that
requires it.
If the format of the auth token is well known (as it is in my case),
you could also just generate this yourself on the client and send that
without having the server do this work.
You can use your login to generate an authentication token for client, which you can use to send attached to your web api requests.
I am using Symfony2.0 and FOSOAuthServerBundle, which implements OAuth2, for managing my APPs clients access to my PHP server.
Everything works perfectly, any token generation, refreshing, etc, etc...
One of the gotten effects is that anytime I enter the APP, I don't need to re-enter my credentials, as the token is still valid or, else, I refresh it using the proper API method.
Typical behavior and all perfect so far.
Now I need to develop a "Logout" button in my APP in order to invalidate that user's token and avoid the use of any refresh_token for him. Sort of revoke his token and/or credentials. In other words, really simulate a Logging Out from the server causing the user to re-enter his credentials next time he gets into the APP.
What OAuth2 sets up for this? Is it a standard behavior with its own API method? Or should I override any behavior in order to getting it?
In case someone's stuck on same thing, I had similar questions, but it turned out to be a conceptual mistake.
Perhaps this may help you:
https://github.com/FriendsOfSymfony/FOSOAuthServerBundle/issues/236
By definition, oAuth2 is STATELESS, so, it does not make sense loging out from an oauth server. To do that, just, destroy the access Token in client side app (We suppose here that you have the control of the app).
But, when a third-party app is connected to your server, you can force the logout mechanism by removing all access tokens that was given by your server to that user of client application. So, when app wants to use one of the destroyed tokens, it will get a 401 HTTP RESPONSE (The access token provided is invalid). Note that if the application has saved the user password in its local storage, it can login automatically to your server without asking the user to enter its password. so, destroying Access Tokens in server side is not a sure method.
I'm writing a web application (that is not to be published by Intuit on their App Center thing) to interact with QuickBooks Online (QBO) for syncing purposes, using VB.NET and ASP.NET. I'm having a hard time understanding how to do this exactly or where to start. What I understand this this:
User accesses your web application and the "Connect to QuickBooks" button (that Intuit requires for In-App authorization) is displayed.
Before the button is clicked you send a HTTP request to get OAuth request credentials using your consumer credentials.
Once the user clicks the button they get redirected to QuickBooks Online (QBO) where they can sign in and then authorize access to a certain company, giving you authorized request credentials.
QBO then redirects back to your site indicating you have authorized request credentials in which you send a HTTP request to get access credentials.
Once you have the access credentials you are basically free to interact with the QBO V3 API.
Using the access credentials you can then construct HTTP requests that send a particular HTTP method with XML/JSON in the body to perform a corresponding CRUD operation in QBO and QBO sends a response to indicate whether it was successful or not.
When your application is done interacting with QBO you simply make sure the access credentials are stored somewhere safe and let the user continue on with their life.
(Side Question: Is this correct or did I miss something or misunderstand something?)
My main question: Do you, as the app developer, even need to construct these HTTP requests or do you use their SDK or something completely different and I'm just not getting it?
I've tried to figure this out but it sounds like you're supposed to construct this all from scratch but then I look in their SDK and they have classes for all the different entity types but then their serializer doesn't serialize correctly and they talk about their DataService class and how you use that to send objects over and using some JavaScript files they host that I have only seen referenced but not explained by them, or anyone really, and information I do find seems to be outdated/deprecated and ya...
Maybe it's just that I'm new to web development and all this is way over my head right now, which very well could be.
(Off-topic-sorta: Is it me or is their site ridiculously broken? It just seems like a lot doesn't work correctly or things are just hard to navigate and find...)
Anyways, thanks for any help anyone can offer. If I need to give more details or ask a different question or something, just let me know. New to this and it's harder than I thought to ask things haha.
My main question: Do you, as the app developer, even need to construct
these HTTP requests or do you use their SDK or something completely
different and I'm just not getting it?
This is entirely up to you, the developer.
If you want to roll your own and construct your own HTTP requests, you certainly can. You almost certainly will still want to use a pre-packaged OAuth library, as OAuth is not trivial to implement.
However, you could also certainly use an existing code library/DevKit too, in which case the library/DevKit will construct the HTTP requests for you.
The DevKits should contain example code to show you how to actually do this stuff, so that might be your best place to start.
You are on right track.
First of all you need to register with IPP to get
ConsumerKey,ConsumerKey secret and Application ID.
https://developer.intuit.com/docs/0025_quickbooksapi/0010_getting_started/0020_connect/0010_from_within_your_app/implement_oauth_in_your_app
if user don't have access token then 'connect to quickbooks' button shows up otherwise you can make it hidden.
request code : https://github.com/IntuitDeveloperRelations/IPP_Sample_Code/blob/master/QuickbooksAPI/DotNet/WebForms%20application/QuickBooksApiDotNetWebFormsSampleApp/OauthGrant.aspx.cs
access code : https://github.com/IntuitDeveloperRelations/IPP_Sample_Code/blob/master/QuickbooksAPI/DotNet/WebForms%20application/QuickBooksApiDotNetWebFormsSampleApp/OauthHandler.aspx.cs
After getting accesstoken, accesskey secret and realmID (companyid) save that to your database.
make sure to encrypt.
so next time same user connect to quickbooks they don't need to go through all of the above steps.
OAuthRequestValidator oauthValidator = new OAuthRequestValidator(accessToken, accessTokenSecret, consumerKey, consumerSecret);
ServiceContext context = new ServiceContext (appToken, companyID, IntuitServicesType.QBO, oauthValidator);
https://developer.intuit.com/docs/0025_quickbooksapi/0055_devkits/0150_ipp_.net_devkit_3.0/0002_synchronous_calls/0001_data_service_apis
I want to create a authorization mechanism for an application based on WebAPI and AngularJs.
I've seen some articles, which use BasicHttpAuthentication, but i really don't like the whole idea of sending username, and password on every request. The more it doesn't fit for me is because i want to use OpenId authentication, where you don't have username/password pair.
I'm thinking about a solution, but I don't really know how to implement it. The concept is that user is authenticated as in an usual Web application - posts a form with user / password or selects an OpenId provider. If the user is authenticated succesfully, it is placed in a static object, which stores the User object for a certain ammount of time. Next a usertoken is generated and passed to the Client Application. The client passes the token on each request to the server, if the user exists in the above mentioned static object with the appropriate authentication token it is authorized to get the data.
Firstly - Do you think this is a good approach to the problem?
Secondly - How should I pass the authentication token, WITHOUT using cookies? I guess it should sit in the request headers, like in BasicHttpAuthentication but, I really dont' know how to handle it.
BasicHttpAuthentication
I'm with you on feeling dirty about caching the username and password on the client and forever transferring it with every request. Another aspect of Basic authentication that might work against you is the lack of sign-off. Other than changing the password, you can't "invalidate" a basic authentication session. Tokens on the other hand, will typically offer an expiration date, and if you want server-side invalidation you can check the issue date and say "any tokens older than issue date xyz are invalid".
Server State
You mention "If the user is authenticated successfully, it is placed in a static object". But this is independent of the token? This sounds like you're wanting to implement server state management of authentication sessions, but this isn't strictly necessary. The token itself should be sufficient for user authentication, managing server state is another potential obstacle. Server state can become difficult to manage when you factor app-pool recycles or web-farm environments (what if you want two services to share the same authentication token, but not require communication with a central "authentication server" for storing the state / session?)
Passing Authentication Token
Headers is definitely a good place for it. Really, where else is there? Cookies, Headers, Message. Other than a browser client, cookies don't make a lot of sense, and including it in the message can muddy your message formatting a bit, so headers is the only remaining option that makes much sense in my view.
Client Implementation
You've not specified, but I suspect you're interested in calling the service from .NET? In which case System.Net.Http.HttpClient could be your friend. In particular, the DefaultRequestHeaders collection. You can use this to add a custom header to store your authentication token.
Server Implementation
When researching ASP.NET authentication recently, I learned a lot about customisation by examining the Mixed Authentication Disposition ASP.NET Module (MADAM). I wasn't interested in using MADAM as-is, but learning about it from that article and examining the source code gave me a lot of ideas of how I could insert my own authentication module into the web stack.