I’ve got a set of APIs written in ASP.NET. These are to be accessed by a web app and native mobile app, and should be protected by the SSO.
I would like to be able have a SSO, where the user can login online and access the web app, and can also login on the native app (via the browser), and it’ll remember their login details (ie with an authorization_token).
I’ve been looking into IdentityServer4 but I’m a bit stuck on which authorization flows I would need for this.
Any help is appreciated, as it’s starting to hurt my brain! Do let me know if I need to explain it better.
For flows, there are today only two flows you should consider.
Authorization code flow, this flow is for clients where you want a user to login/signup, like a mobile app or web-application. Meaning, you have a user and a browser involved here.
Client credentials flow, is all about machine to machine communication, where you have no user involved.
Related
Problematic
I have a working Keycloak in production and I need my users to log into a mobile app, developed using react native using that Keycloak. Till now I was using the normal login flow through the in-app browser as AppAtuh, but now I received a request from users, to say in the app while logging in.
What I've tried
I made the Keycloak theme for the mobile login ressemble the Mobile App UI so much, that it could be just opened using react WebView as a normal screen.
On the paper, this idea works, but in real life, I cannot take advantage of the Keycloak ID cookie placed. So whenever the WebView open, a new session with cookies are generated. It's not useful.
I started calling keycloak endpoints myself from inside the mobile app. It's not an easy job, because some endpoints doesn't works because of OTP configurations that I've done.
Secondly, this Idea works for simple process like login, but does not work very well for registration or reset-password. And it's just an example. My Kecloak does have a list of Authenticators which uses phoneNumber and some cookies to login.
Specifications
I'm using Keycloak 10 (started with keycloak 6 a year ago)
The mobile app is developed using React Native and Expo. Tthe first login flow was using the library Expo AppAuth and the second, React native WebView
Have you read that? I think you should consider using Custom URI scheme for your Keycloak OpenID Connect client and use default phone browser. This might be helpful as well.
I like to distribute content from within our Content Management System to several online channels like the website, twitter, linkedin and, last but not least, Facebook. Editors can create items and, eventually after a worfklow process, distriute them amongst the different channels.
Off course the website is no problem (it's still a CMS, isn't it). Twitter integration was rather simple. But now I like to create a connector with Facebook.
The approach is like this.
Create a Facebook app: TheCMSFacebookConnector
Give it permissions to write on a wall, create events, add photo
collections, etc. A customer buys the CMS
Within the CMS Manager there is an action to connect the
TheCMSFacebookConnector app to the customers' (corporate) facebook
account
The OAuth dance is performed and the accesstoken en accesstoken secret are stored
From now we use the REST API to add content to the customer's corporate wall. This is exactly the way i did it for the Twitter integration.
But.........
choosing the right integration type
When I create the Facebook app, the Facebook asks me to tell how the app integrates with Facebook. The integration types that seems to fit the best are Native iOS App or Native Android App. In fact the CMS acts as a Native App as well. Has anyone a clue which App Integration type i have to choose?. And are there other parameters that are important to set in a, maybe, different way?
Choosing the authentication flow
A second question is about the OAuth dance. If we distribute the CMS amongst our customers, they host the CMS Manager environment in their DMZ with their own (mostly) corporate URL or, better, they host the CMS Server within the LAN and the Publication Server in the DMZ (we provide some tools to synchronize those servers)
When I do the OAuth dance, the CMS Manager (which is a webapplication) has is own URL. So in the definition of the app i cannot name an unique value for App Domains. From within the "OAuth dance"" code the redirect URL seems to have a connection with the App Domain and cannot be set in a dynamic way. So is it true that for the "OAuth dance" the only valid method is the client-side authentication flow?
Hope that someone can help me with, especially, the first question. Thanks in advance
E.
So is it true that for the "OAuth dance" the only valid method is the client-side authentication flow?
Not necessarily – you could always have an address from your app domain set as redirect_uri, and have that redirect to the CMS users web address afterwards (via a GET parameter in redirect_uri or something like that).
We are developing a hybrid mobile app (code is written in HTML and runs on browser shell as a native app on the device). We need to authenticate the user against an external security manager. I've seen the Gmail App in iPhone which opens a browser to authenticate the user. We are also looking to do something of that sort. We just need to gather your thoughts on how authentication can be done with some external security manager in a mobile app.
Also I noticed that Dailymotion website was able to know if the user is authenticated with Facebook. This looks like a cross domain authentication.
Can you please share your thoughts on how Google and others have implemented it?
What you are looking for is OAuth and OpenID services to federate your login. Depending on the architecture of your system you can implement whichever one you like or even a hybrid of both.
Take a look at this link: Federated Login for Google Accounts
It provides all the useful information you need.
Hmm this question seems old but in case you haven't found an answer here's how I did it with my hybrid apps :
open url on client side with the provider's (facebook/twitter/instagram) url for login
the user logs in and is redirected to the server's callback url (my server is written in nodejs)
once I've got the access token from the provider. I save this token and then create a token for the client to reuse every time the user wants to access a protected ressource.
Download the apk and test it.
If this is what you're looking for you can checkout both the client side code at : https://github.com/malikov/Authenticate.me-client-cordova-ionic
And the server side code at : https://github.com/malikov/Authenticate.me-Node-Server
Cheers
I have an app that can be accessed on mobile phones, both iOS and Android. The app has a social component to it, so people are sending data to and from my server.
I also have an interface for this app that will be accessible through Facebook.
When logging into the app via mobile device, using the native app for that device, one can just log in with standard username and password.
However, obviously if a user accesses the app in Facebook, they will expect to already be logged in since they are already logged into Facebook.
So I need to make it so that my app can take a log in from Facebook, pretty much automatically (?) for users who are coming at it from within Facebook.
Further, it's possible (dare I say "likely"?) a user might access the interface from both Facebook and one of the mobile versions of the app. In which case I need to be able to ensure that the username/password authentication they use on the device points to the same account associated with their Facebook login.
So... all that said... what kind of Facebook authentication should I be studying and implementing.? I'm looking at their documentation right now, and like all documentation, it's not easy to grasp. There is server-side (authentication code flow?) and client-side (implicit flow?), and authentication tokens, and I'm already a bit lost.
Also, I assume Facebook's approach is to want to take over my login in process completely, not live side by side with my mobile-device-only login, but I'd like to make sure users have the option of not using Facebook authentication if they don't want.
Can someone point me in the right direction for how to do this? Basically let me know which part of the documentation I should be focusing on.
And are there any gotchas I should watch out for?
Your server will receive a signed request when your app on facebook.com is loaded; from this you can find the FB uid of the user.
If you obtain the FB uid for users of your mobile device clients you'll be able to match your app's accounts between mobile device & facebook.com clients.
The bottom of the main authentication docs page gives links to further documentation for different client types. The main mobile authentication page has side-bar links to tutorials & SDKs for iOS & Android. Alternatively you could use the server-side OAuth flow as your devices have browsers that support this.
Once you've completed authentication on the mobile device it's simple to obtain the uid.
You can also use the Facebook authentication flow instead of your own username/password authentication.
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