I am building a mobile app for my web application. I have decided to use cordova , So basically it will be single page web app. I have also made a REST API server which uses key and secret to verify each request. In web app I can use key and secret to make request to my api server, But how do I do it with in mobile app? It would be bad idea to store key and secret in mobile app (May be it is bad idea for web app aswell). I am thinking of changing Authentication process in api server aswell. What should be the best way to call this rest api server from mobile app and authenticate these requests. Should I generate tokens for each user request and verify with key and secret? I think I will not need oauth as this service will be for my webapp and mobile apps only, we don't have need to allow others third party service to access our api.
Should I generate tokens for each user request and verify with key and secret?
Yes.
It might be worth using OAuth if you can use an existing implementation from somewhere. It's a standard protocol, so is more likely to be secure than something you invent yourself.
It also means that if you ever want to let third party apps log in in future, you can. You might not think you will ever need it, but you never know. It's also a good idea so that if you ever work on another project that needs oauth, you have had practise.
Related
I have a mobile application built upon Ionic Framework which uses many Cordova packages. We are upgrading the app from Ionic3 to Ionic5. In the Ionic3 application our .NET API was responsible to managing user logins. Going forward, in the Ionic5 app we will NOT be managing user credentials - we will be using 3rd party Identity Providers such as Google, Facebook, and Twitter.
We have implemented the Cordova packages to handle external authentication with Facebook and Google and it works fine. How do we tie the token that is received from Google/Facebook to our .NET API? When we try to use the token provided from Google/Facebook we - of course - get a 401 because our .NET API doesn't know about that token as it was issued from an external source.
I am aware of the process of how to enable the schema described here (External Authentication Services w/ASP.NET Web Api) but in this case the user agent browses to the Web Application in the browser. This is not true in my case as the user agent will be using a mobile application not a web site.
But I hope the principal is the same. But I'm missing something here.
The user will open the mobile app, authenticate with Google/Facebook and be issued a token. Now, what needs to happen to get that token to be recognized by my ASP.NET Web Api?
For example. When I registered my mobile app with Google Developer's Console I selected that the type of app is an Android application and was issued a Client ID for Android now how can I use this token in my ASP .NET Web API? There MUST be some way to tie the two together or some article out there.
Thanks in advance for your assistance!
Also, I looked at this post and see its 11 years old. Is there something here that I should be doing? Please help point me in the right direction. how-can-i-verify-a-google-authentication-api-access-token
It is about data ultimately, and identifying users in a consistent manner, then tracking their history with your app / business.
SOCIAL LOGIN PACKAGES
These are often cheap and nasty solutions that add complexity to your apps as you are finding.- especially when you need to look things up by user.
OPTION 1 - COMPLEX APPS
Your API could look at the token issuer (ISS claim in the token) and download token signing keys from either Facebook or Google - if JWKS endpoints exist. Then create a user from the access token's sub claim if required.
OPTION 2 - SIMPLER APPS
Deal with only a single type of token in your UIs and APIs, which will work like this. It moves the complexity to your Authorization Server (AS):
You have an Authorization Server (use Google maybe) to deal with token issuing and other central OAuth concerns
You have multiple Identity Providers (eg Facebook + Google) to support different login methods for users
During login Facebook posts a token to the AS
Then the AS issues its own token to your UI
The AS may be able to use Account Linking to provide a consistent user id regardless of login method
There is a learning curve in getting this working, but once done it can easily be scaled to many apps with zero code changes.
The proper answer is Auth0... see the below sequence diagram!
I have hosted my REST services on API management and consuming those in the Azure Web app service which consists of only HTML pages, javascript files and CSS files.
I would like to know how to restrict accessing the REST endpoints of the API management only from the web app without Azure AD and OAuth setup.
Client side application sources are by design available in clear text to anyone using it. Any user can open developer tools in browser and look at code you've written to make app work. So even if you secure your REST API with some secret and use it in app code to talk to that REST API anyone in the world will be able to take that secret our of the app and call your REST API directly, and you would have no way to distinguish their calls from calls made by your app.
OAuth and AAD would work to a certain extent but even they allow you to authenticate user, not the app. Same user can easily trace calls made by your app to REST API and reproduce them in any other app, and you again would have to way of figuring that out.
I think your best bet is to throttle calls made by a certain user identifying it any way you want (even if by IP address).
You can use Certificate authentication from web app to api management. The ssl certficate thumbprint on you web app you can validate in api management policy.
I am writing an iPhone app that uses Facebook extensively. Right now, I'm getting the access token using the iPhone Facebook SDK. This returns me a standard access token.
I'm sending this token server-side and using it for many queries successfully. However, there are some queries that require an access token signed with the Application Secret, which the iPhone app sdk can't do client-side due to security vulnerabilities (specifically I'm trying to use dashboard methods).
So my question is: is there some way I can have Facebook upgrade this iPhone access token server-side to contain the signed secret? Or do I have to validate server-side from the beginning to do this?
The docs say that with the 'Server-side flow' method, once the user allows your app, you get a code generated by the server that you must send back with your App Secret to get your access token. The iPhone SDK uses 'Client-side flow' method, and it seems to skip this step, so I'm not sure how to get this code. So I guess the question boils down to, is it possible to upgrade a token gotten with the 'client side flow' method to one that can be used fully server side.
The answer is no.
The user token and app tokens are different and you can't convert one to the other.
Because you have a client app, I don't recommend that you embedded your app secret (as you point out).
For your app, I recommend that you create a web page on a server you control that gets and use app token that makes the calls you want.
I'm looking to implement Single Sign On for a native iOS app whereby logging in with this single sign on gives the mobile device authenticated access to our private service in a fashion that is somewhat similar to oauth.
The marketing text on openid.net suggests that "OpenID is a safe, faster, and easier way to log in to web sites.". Emphasis on web sites.
So the question is: Is it reasonable to implement openID on a native mobile app, or is openID only for web sites.
I've been scouring the web and I'm not finding a way to fit openID in as my login option.
The best way to do this seems to be to use a UIWebView and render a log in page from your site in it. Once the user logs in, they'll be redirected back to your site and have an auth cookie, which you can extract, store, and send on subsequent HTTP requests to the server.
See this, which has a sample code link at the bottom.
OpenID sends its messages as a series of HTTP requests and responses. Your app and the openid provider must communicate to each other via HTTP post, and you will need to redirect the user to corresponding URLs, and have a URL for the user to be redirected back to. As such, you will probably find it difficult to integrate with your app.
Derek Knight claims to have been experimenting with iOS and OpenID using the Janrain Engage iOS SDK. Although the github link he references no longer exists and he doesnt provide a complete and verified solution, he does offer an idea for how it might work.
OpenID and iOS development - gordonknight.co.uk
Janrain Engage for your iPad Apps
The accepted answer diminish the OpenID protocol. OpenID is a federated authentication protocol aiming simple SSO experience, its a web based protocol but it can be implemented if you design an authentication broker.
APPs share nothing, apps should never access anything but identity token and access token (if allow). here is a link to get you starter in the right path to build seems-less SSO in the mobile between apps regardless the app isolation level.
https://www.pingidentity.com/developer/en/resources/napps-native-app-sso.html
Libraries:
https://github.com/openid/AppAuth-iOS
https://github.com/openid/AppAuth-Android
I have a Rails application for which I use devise to authenticate my users and this works great. I now want to write an iPhone application (not just a WebUI but a proper APP) that accesses the same data and so requires the same authentication. How should I go about doing this?
I want to login using devise and keep the session open so that queries back and forth work as they do on my website. I am very new to both rails and devise.
I'm trying to do the same thing actually. I also have a Rails application, using the Devise Authentication Gem that I would like to create an iPhone App for. I don't know if I have a good answer for you yet, but here's some things I've learned along the way...
According to the README on the Devise GitHub page, it seems that Devise is implementing RESTful authentication with these 2 modules:
Database Authenticatable:
encrypts and stores a password in the database
to validate the authenticity of an
user while signing in. The
authentication can be done both
through POST requests or HTTP Basic
Authentication.
Token Authenticatable:
signs in an user based on an authentication token
(also known as "single access token").
The token can be given both through
query string or HTTP Basic
Authentication.
With HTTP Basic Authentication, your iPhone app won't have to re-authenticate with each request. You will only have to authenticate once, then the framework will remember that it has authenticated.
A few resources that may be helpful for you getting started:
ASIHTTPRequest
Objective Resource
This is a very general answer, but you probably want to use a webservice, in this case exposed within the devise api.
On the iPhone side, it's a web service call, see the docs for "URL Loading System Programming Guide" in the iphone sdk, or maybe this answer: Using a REST API and iPhone/Objective-C
This link answers the question of how to auth an Objective-C app against rails and store the login/password in user defaults for later use:
HTTP authentication between devise and iphone app
Use the method above to add authentication to your Cocoa / Objective-C / Iphone / Mac OS X app against a Ruby On Rails backend.