We are developing multiple apps for our client which all can be used using same credentials(credentials of there company portal).
So we want to implement something like single sign on, such that user need not to login each app.
I have already gone through these links
http://msdn.microsoft.com/en-us/library/live/hh826544.aspx
http://stackoverflow.com/questions/5598411/single-sign-on-choices-to-use-with-windows-phone-7
Here is what i need exactly:
step 1.) When user login to one app(say App1), the portal will return a token, ineed to store this token somewhere, such that only authorized apps can access this.
Step 2.) when any other app(of same group) launches it will check on the location for the token and if token exists, it will not demand for credentials.
Step.3) When user logs out from any app, it will remove the token from shared location.
We have already implemented this in IOS using keychain(possibly wrong term as i am not ios developer).This keychain provides a common space for the apps signed with same certificate.
As per my knowledge uptill windows phone 7.5 there is no possibility. Does windows Phone 8 has something for this.
If not i am open to any kind of suggestions to serve the purpose.
P.S. : Security is our major concern, So when you suggest please let us know you think there could be any security concers though hack or phone loss.
Thanks a lot..
I hope to be corrected but this won't work. Apps are isolated and can't share things like data packets and such.
i am not a windows app guy.
but a trick can work.
caution:
following can raise security concerns if API token expiration time limit is not properly considered.
use firesharp / any XMPP service (suitable for windows client) to send api tokens to other devices like notification message.
handle the notification in such a way that token is not displayed.
and also remember, there is no such think as log out in API authorization.
you will have to restrict access with token expiration time limit.
Related
I've been searching for a solution that makes sense for the past few days, so forgive me if I overlooked something or am ignorant to the correct path.
I have an existing Website built with asp.net framework MVC where users register for Individual Accounts and are stored in a MSSQL Database. I'm creating a Xamarin.Forms app where we want users to login with their website credentials.
I've been looking at Microsoft docs to try and accomplish this. In the past I created an Apache Cordova app (2014) that communicated in a similar fashion successfully (potentially in an insecure way) that called the /Token endpoint and Authenticated the user with 'grant_password' flow and returned the user data to the app.
So I landed on this documentation: https://learn.microsoft.com/en-us/azure/active-directory/develop/v2-oauth-ropc
However, from what I can gather it basically says this should be avoided moving forward and a MSAL approach should be used if possible.
After reading through hours and hours of documentation trying to make sense of it all, I can't seem to grasp what my options are. It seems to me that in any MSAL flow, users will have to login with Microsoft accounts or other social accounts (facebook, google).
Am I missing something?
Am I going to have to go against Microsoft's advice and end up storing the client_id and client_secret within the Xamarin app source code? Which from everything I've read is a big security concern, especially with Android apps.
References: 1. Restrict API requests to only my own mobile app 2. How to secure an API REST for mobile app? (if sniffing requests gives you the "key")
Any help or direction would be really appreciated. Thank you
Your focus should be on requirements + understanding preferred designs rather than jumping to a technology.
DIRECTION
Standard modern systems look like this:
Mobile apps use OpenID Connect to sign users in
Authorization Server issues access tokens to the mobile app
APIs authorize requests via JWTs containing scopes and claims
Aim to make iterative steps towards this type of architecture.
PATTERNS
Plug in an Authorization Server, which uses your existing database as a credential store
Mobile app uses AppAuth Libraries to sign users in and receives access tokens
Back end can handle JWTs without data security risks
DIFFICULT AREAS
Your existing back end may have no support for mobile clients, and be too web focused - eg requiring cookies to access data, so may need to be split in be into 2 entry points.
Choosing an Authorization Server (while you are learning) is difficult, because you may not know what you want yet.
The mobile app will spin up the system browser and present a login page from the Authorization Server, so the login UX could be unexpected.
STEP 1
Ensure that you can authenticate from the mobile app, then make API calls with JWTs and ensure that requests for data are properly authorized. This could use ropc and involve a temporary API. But the deliverable should be that your back end now supports calls from mobile apps.
STEP 2
Integrate AppAuth into the mobile app, which is tricky but there are resources online such as Curity Mobile Guides. Update the mobile app to use the Code Flow and integrate an Authorization Server, then deal with connecting to credential stores.
SUMMARY
This stuff is hard and reflects the cost of modernising architectures. It requires people agreement as well as the technical stuff. Happy to answer follow up questions if it helps.
My objective is to verify a 3rd party app (that uses google for auth/sign-up/sign-in) is connected to a google account, by calling a google API from my google app. Is this possible with the current google APIs? I haven't been able to find any documentation on this which leads me to believe it is not possible, likely for privacy/security reasons.
The best I've come across is a call to: https://www.googleapis.com/oauth2/v1/userinfo?alt=json which doesn't seem to return anything about connected accounts. And https://developers.google.com/admin-sdk/directory/reference/rest/v1/users which is for users in an enterprise domain which doesn't help me as my app is for consumer users.
There is no way for you to know what apps a user is using on their account. Even if its your own app there is no way of knowing. Unless the user has authorized you and you have an access token then you will know they have verified your own app.
Having an api which would tell us what apps a user has authorized IMO would be a bad idea.
I Guys, i have to create a mobile app that need to make a request to a laravel endpoint, app no require registration or login, which is the best way to protect my api? To make sure the only my application can call it?
Thanks!
There's no full proof method of securing your api, because with the right tools and following some tutorials on the web, anyone could view your whole api request, headers, tokens, etc.
Anything you do or store on the app is already compromised, so signatures,ssl, encryption,tokens, etc are not that helpful if malicious users have access to the app. It can make it more troublesome for malicious users, but a dedicated one could overcome it.
Using authentication atleast forces users to register before they can use your api and you can block the user when needed. Along with requiring email verification, users who wish to misuse your api would then need valid email addresses atleast. But since you mention securing without authentication, this goes out of scope.
You can secure your api somewhat by using rate limiting. laravel has an inbuilt rate limiting with the throttle middleware. You can use this to restrict the number of times an api can be called in a particular time interval by an ip address.
Next would be Ip blocking. If any malicious activity is found, you could block the ip address. But this can be overcome with a vpn, and a malicious user could also block someone elses ip in this manner.
Captcha can help against bots, but would also annoy regular users.
Another method would be restriction with cors, those who have faced cors issues know exactly how annoying it can be, but it wont work on native apps (or you could try pwa).
And in a worse case scenario you could go with some terms and conditions and some legal action
A simple solution You can create a table for devices with api key which will be generated for each device app, and always use it to send requests to the api end point, then used it to fetch data from the rest api. The same process like if you are loging in, but you will use the api key unstead and the key will be fixe not refreshed evrey time.
I'm writing a web application that reads my personal calendar data, crunches stats, and then spits them out for the world to see. I don't need an authorization flow. Is it possible to leverage the Google APIs without going through a user sign-in flow? In other words, I want my personal Google account permanently and securely signed in to my server without the risk of my token invalidating or having to re-auth.
Right now I'm signing myself in with an offline token, then uploading the authorization file onto my server, basically spoofing the server that I already auth'd. Is there not a cleaner way?
I've spent hours reading through the API docs and Auth docs, but haven't found and answer. If there is a page I've missed, please point me to it!
PS. I'm using the Calendars API through Python/Flask on Heroku, but that shouldn't matter.
An alternative approach is using a service account while sharing your calendar with that service account. See https://developers.google.com/accounts/docs/OAuth2ServiceAccount
So, you want to be remembered.
If you want to dispose of any kind of authenticacion but yet the user needs to be recognized you should be using a cookie.
On the server side that cookie should be used to select the offline token.
Of course, without that cookie the user needs to be authenticated in any way. I would make them reauth by Google so you get a new offline token.
Hope that it helps.
I am working on a Windows Phone app that utilizes the Facebook API. To do that I need the user to login and authorize my app, so that I can get an access_token. I've already done that, it works fine.
The question: how to keep using the Facebook API on the next launch of the app without having the user to log in again?
What I do: When the user logs in I save the access_token and the expiration time. Later, I can use the access_token when making API calls. This is all fine.
The problem: with offline_access not working anymore, the access tokens I get are valid for 60 days. This means that after 60 days they will stop working. Can I do something to renew those tokens without asking the user to login again?
My research:
I read the documentation, but it seems to mention only Android and iOS. While I assume it would be similar for Windows Phone, I am not able to find out what to do. The Facebook libraries for those other platforms have something like:
facebook.extendAccessTokenIfNeeded(this, null);
I was not able to find similar method for Windows Phone. While I read somewhere that this does not actually work for Android, it hints that there must be a way to do it.
I read about the new endpoint allowing renewing of access tokens, but it seems to only be able to extend short-lived tokens to long-lived. For me it is a bit unclear from the documentation here(Section 4):
https://developers.facebook.com/roadmap/offline-access-removal/
Any help is appreciated, thanks.
Follow the Offine Access Removal Guide on the link you provided. It has the API Call you can use to get a long-lived Access Token for the user - this is the replacement of offline_access.
Specifically, see Scenario 4.
In theory, Windows Mobile should fall under Exception 2 / 3. See if the Windows Mobile SDK has an option to access the access_token in a similar way to iOS and Android.