ASP.NET MVC authentication for iPhone application - iphone

This is for an ASP.NET MVC application. For browser based access on my normal controllers, I'm using standard forms authentication and auth cookies.
My question is how I do the same for an iPhone application. I have a set of RESTful controllers that the iPhone application uses directly, but I'm not sure how to go about authentication...
I was thinking of having a special Login method that returns the auth cookie. Then I can use the standard Authentication attribute on the ASP.NET MVC side, but I'm not sure how to handle this on the iPhone side? Can I store this cookie and have it automatically sent with every request?
Perhaps there's a better approach altogether?

If it is RESTful you can use an NSURLConnection and send your server the appropriate HTTP headers the API requires.
http://developer.apple.com/mac/library/DOCUMENTATION/Cocoa/Conceptual/URLLoadingSystem/Tasks/UsingNSURLConnection.html

Related

.Net5 using a centralized web applications for login

I'm building a platform on .Net5 that will consist of at least 3 MVC web applications: User, Admin, Product. Authentication is performed on the User application where we can take a Username/Password to log the user in. The User Application also has the Forgot Password/Reset Password, etc functionality on it. Authorization is claims based. Based on this document I believe I would fall into Figure 9-2 Authentication by identity microservice, where my other microservices are web applications rather than APIs.
The issue I'm running into is trying to figure out the proper way to implement this.
Do I use JWT or Cookies for this? The article above does have a link for cookie sharing but wouldn't JWT be appropriate?
If I did use JWT, how do I pass it back to the server if I used something like #Html.ActionLink? Or is it expected that I would be using a front end framework like React and thus making any calls back to the server manually?
Again, if I'm using JWT, how would I pass it from the User application to the other applications?

What's different between server oriented WebAPI and mobile app oriented WebAPI?

RESTFul Web API usually is designed for server oriented services, in most cases, the client will request an access token with its apiKey/apiSecret.
In mobile app oriented WebAPI, especially consumer oriented applications, the end users don't care apiKey/apiSecret, they just know their username/password.
Should I say the mobile app is actually some kind of browser, it will transfer username/password to get cookie, and access the Web API with cookie to get back JSON object from the server. And the server can use cookie/session to track the user operation via Web API?
So their authentication method (token and cookie/session) are the major difference ?

Sencha touch 2 oauth2 authentication

Using OAuth 2 I need to limit user access to permitted resources only, where the connection to the API is made through an ext.js REST proxy. The ext.js proxy takes care of data retrieval and maintaining the model relationships. I haven't found an elegant way to make different calls from the proxy to the backend depending on the user logged in.
I am wondering if the proxy has to be different for each user logged in to my application because each user has their own access token.
Another option would be to make the proxy know about the logged in user during the proxy initialisation process and save this information in a persistent way.
Has anyone solved a similar situation before?
The article gives a detailed explanation on how to use OAuth2 with Sencha Touch.
http://www.sencha.com/blog/meetcha-using-sencha-touch-to-build-a-mobile-app-for-meetup-com/
There are several ways to use OAuth. One uses redirects after the initial authentication (for this you might use an iFrame inside a Sencha login view). The other uses your backend server as an intermediary to the OAuth server that can avoid the iFrame solution but requires more logic on your server.
You can then use a session cookie which will be resent with all HTTP requests including your REST calls. Most back ends support session cookies and so all you need to do then is look up the user ID you stored in the session object as part of your REST API code.
Another option is to set a custom HTTP header in each REST call that requires authentication. To avoid duplicate code, create a derived class from the Sencha proxy class to set the header containing the access token. You can store the access token in a Store or on the Application object or as a static value on the proxy. I've done this for both REST proxy calls and Sencha Direct proxy calls.
AJAX Proxy header property:
http://docs.sencha.com/touch/2.3.1/#!/api/Ext.data.proxy.Ajax-cfg-headers

Design for Authentication schema for A WebService called by Mobile Client

I've a (Json) WebService that have multiple methods.
I need to call these methods in a Mobile App. And need to add authentication schema to this Service.
Note, there's a Login screen in the Mobile app.
What is the best way to accomplish that?
One suggest (but I don't desire) is:
Have the All WebService methods to have two extra Parameters (UserName and Password), thus send the authentication with each request.
Other Suggestion might be:
What If I used OAuth authentication schema; which as I could understand is to send Username&password once, and then have the server send the client some token and then the client uses it in subsequent calls.
Please suggest me!
Sending username/email+password with every request requires you to persist both within the application which is bad.
OAuth is the perfect way to implement authentication for mobile devices. Following standards is good.
The bottom line is that it doesn't make sense to make any short-term expiring token for the app (unless it's a banking app or an app accessing CIA/FBI/UNB facilities).

ASMX Web Service authentication

I want to authenticate web service user on first web method call only & use his identity for other web method calls.
How web service maintain the user identity?
ASMX web services only support the types of authentication directly supported by IIS.
Alternatively, you could implement your own authentication using SOAP Headers, but then your authentication code has to be perfect.
You can set up a session using 2.0 or a cookie and than passing the data will be easy.
Let me know.