The PWA App access is based on the user credentials passed from the User's Mobile App (where our PWA App is being exposed within the i Frame) and the two parties are contractually bound trusted entities. We now have a 3rd party PWA App that is called upon based on a specific service filter selection by the User. However, the Trust exists between our PWA and the 3rd party PWA, but not between the User's Mobile App.
How can the session be maintained across this flow?
Related
I am developing an application using Supabase, Flutter and Google OAuth and I would like to know if it is possible to have a single clientId and clientSecret for each device type (ios, android and web) so that I don't have to implement a different authentication workflow for each device.
I have tried looking around the Google Console and see if it is possible to create a single authentication API for multiple devices. I also tried searching online.
There are sevral types of Oauth2 clients.
installed app client (for applications run on the machine)
web app clients (for applications run on web servers)
Android app clients (for applications run on android devices)
IOS app clients (for applications run on Iosdevices)
The authorization method for these three types is different, the code used to authorize them is also different. They can not be mixed.
Android app requires SHA-1 certificate fingerprint
Ios app requires App Store ID
web app requires a redirect uri
So the answer is no you can not create one type of credential to work with Android, Ios and web, you need three different credential types.
a bit of sdk magic
If a user authorizes your web app, they may not need to authorize your android and Ios apps as long as the credentials are all part of the same project on Google developer console.
Last I checked this is not true the other way around, if a user authorizes android or ios first and then tries web they will need to authorize again.
My guess is this is something baked into the android and ios sdk on googles side that is not part of the respective client libraries for web. Either that or its something in the authorization code grant that isn't in the mobile code grant type for Oauth2 I have never bothered to dig to far into it.
I read this question that was asked since 2014-2016. Right now is still not support?
https://lists.jboss.org/pipermail/keycloak-user/2016-February/004821.html
http://lists.jboss.org/pipermail/keycloak-dev/2014-January/001116.html
From link above. Here's my thoughts on device mgmt, both UI and protocol:
Scenario:
An iOS device as a "Brokerage App" installed. The app needs to do REST
invocations to be able to trade stocks, etc. Devices must be registered
in order to obtain permission. Flow would look like this:
User installs app on iPad.
User hits login button on app.
User is redirected to browser with a Keycloak server URL
User enters in credentials
User is redirected to "Device Registration" page. Keycloak asks user
if it authorizes access to the device.
Keycloak registers the device under the user and generates a device token
User is redirected back to iPad ap
iPad app gets auth code from redirect URL
iPad makes REST request to obtain auth token AND a device token.
iPad app stores the device token.
Thanks
I have a RestAPI which will hit to authenticate the user. This api is to android they hit this api to allow user to login to our app
My requirement is this.1) If user has cell phone say xyz phone with IMEI "xyzz1234". Now if he tries to log in from his 2nd phone than he should not be allowed to login from 2nd phone. He should log out automatically from abc device.
As i am using ionicv1 framework for mobile applications.
You can update the deviceID in your database once the user Sign in on another device.
In your signIN API, validate your deviceID.
For the case of login state saved in your app, you can hit an API at your dashboard on startup which can make the person logout.
This could be one possible approach :)
When a user clicks on the login with Facebook button on our website, we call:
https://www.facebook.com/dialog/oauth?client_id=xxxxxxx&
redirect_uri=http://xxxxx.com/Account/FBLogin&scope=email,publish_stream
Inside of our FBLogin (string code) method we do two things. First we call:
"https://graph.facebook.com/oauth/access_token?client_id=xxxxxxxxx&
redirect_uri=http://xxxxxx.com/Account/FBLogin&client_secret=xxxxxxxxxxxxx&code=" + code;
Then, if the FaceBook login was successful, we login the user into our site.
What is the equivalent of this workflow in iOS? We basically want to authenticate the user on our servers as part of the Facebook authentication. So when the Facebook authentication returns successfully, our user is also logged into our system.
Many thanks!
If you're using the Facebook iOS SDK, the SSO (single sign on) workflow is more like the Javascript SDK's workflow because the user is presented with what's similar to the JS SDK's popup: either in the form of a UIWebView, Safari Browser, or Facebook app (depending on the user's setup).
One of the most compelling features of the iOS SDK is Single Sign-On
(SSO). SSO lets users sign into your app using their Facebook
identity. If they are already signed into the Facebook iOS app on
their device, they do not have to type a username and password.
Furthermore, you can get permission from users to access their
Facebook profile information and social graph.
SSO primarily works by redirecting users to the Facebook app on their
devices. Since users are already logged into Facebook, they will not
need to enter their username and password to identify themselves. They
will see the Auth Dialog with the permissions that your app has asked
for, and will be redirected to your mobile app with the appropriate
access_token.
Developers should be aware that Facebook SSO will behave slightly
differently depending on what is installed on a user's device. This is
what happens in certain iOS configurations:
If the app is running in a version of iOS that supports multitasking,
and if the device has the Facebook app of version 3.2.3 or greater
installed, the SDK attempts to open the Auth Dialog within the
Facebook app. After the user grants or declines, the Facebook app
redirects back to the calling app, passing the access token,
expiration, and any other parameters the Facebook OAuth server may
return.
If the app is running in a version of iOS that supports multitasking,
but the device doesn't have the Facebook app of version 3.2.3 or
greater installed, the SDK will open the Auth Dialog in the Safari
mobile browser. After the user grants or revokes the authorization,
Safari redirects back to the calling app. Similar to the Facebook app
based authorization, this allows multiple apps to share the same
Facebook user access_token through the Safari cookie.
If the app is running in a version of iOS that does not support
multitasking, the SDK uses the old mechanism of popping up an inline
UIWebView, prompting the user to log in to Facebook and grant access.
The FBSessionDelegate is a callback interface that your app should
implement: The delegate methods will be invoked when the app
successful logs in or logs out. Read the iOS SDK documentation for
more details on this delegate.
... when the user finishes either signing in or not signing in and returns to your app from the "popup", your app has to decide what to do based on whether or not the user logged in/authorized the app (and a valid access token received).
Please read this for more info:
https://developers.facebook.com/docs/mobile/ios/build/#implementsso
I'd like to build a web application which allow iPhone users to save a short memo as a todo list on the web server. The user must logon on Facebook on the iPhone before submitting a memo.
On the server side, how can I tell whether the iPhone user has logon on Facebook or not?
In a native app, FBConnect can be used to establish trust between the app and Facebook. (FBConnect calls an fbDidLogin delegate method).
It's up to you to establish trust between your iPhone app and your web service, but once you have, the app can report the FB login state along with it's requests.
Assuming you're just building a web application, I don't understand why it would be different then building a normal web application that uses fbconnect and graph api. You just happen to design it to fit a mobile browser. There's a section on authentication.