How to implement QR code cross login from mobile app as authentication method for website or webapp in a vendor agnostic way? - django

I am using Django 2.2 for my webapp.
And I have been looking for tutorials that cater for QR code cross login to webapp using mobile app.
Basically the workflow is like this:
expected workflow
User arrives at website on desktop
Given a choice of username/password or QR code login (We assume user is registered)
User chooses QR code to login
User is prompted to install mobile app (can be android or iOS)
User installs mobile app and logins using username/password.
On mobile app, user then agrees to future login using QR code as alternative (this is done once)
After this, in future logins, when User chooses QR code to login as per step 3. They use the mobile app to scan QR code generated on the website login page.
The mobile app then uses FaceID or FingerPrint ID (assuming iOS) to then allow login. The user presses a Yes button on the mobile app to confirm login.
Somehow the webapp is notified dynamically and allows login on the desktop browser.
I don't quite get how the mobile and the web app at the backend all work with one another to achieve this seamlessly.
What I did find
I did find this library https://github.com/aruseni/django-qrauth which seems no longer maintained. But I still cannot quite get how the flow works between mobile app and webapp backend.
I also found this https://medium.com/#ksarthak4ever/django-two-factor-authentication-2ece42748610 which seems to use the mobile phone as a 2FA device. Not exactly the use case I am looking for unless I misunderstood.
I did find this article https://backendless.com/how-to-implement-mobile-to-web-cross-login-using-a-qr-code/ which is what gave me the term "cross login". However, the article is tilted heavily towards this particular vendor.
I am looking for an "understanding" of the concept without being reliant on the specifics of the vendor implementation.
What I am not looking for
In case, my question is poorly phrased and gets misunderstood, I have included this section to make clear what I am not looking for.
I am not looking for the use case where the QR code serves as a 2FA confirmation for the authenticator app.
I am also not looking at code examples yet. I just want a clear understanding first of how things work between the mobile and web app. I believe JWT is needed though I am guessing.
A workflow is more appreciated than actual code because I want to gain an understanding first of how this works.

The key concept is that login occurs when a user and browser are matched. A user means a user(or a user device) already recognized(authenticated) by the server.
user's PC browser requests QR login to server (without any account information)
server makes login request key and send the key to the user's browser. the key is displayed as QR code. (the role of this key is to identify the browser)
user's already logged-in device(user) read the key(QR) and sends a login acceptance request to the server with the key.
At this point, the server knows who both the user and the browser are.
The server allows the browser to log in as the user.
The key to identify browser could be session or web socket channel or any other form of information.
The server must store the key until the login process is complete.
If a valid login acceptance request is received, the server should prompt the browser to log in.(server->client, push). there are several techniques for accomplishing this.(polling via AJAX, Web socket, push notification services, etc..)
I'll explain it with Django-channels web socket framework. (In this case login request key and channel name is same. but different key and channel name is also okay.)
browser: user chooses QR login. (without any account information)
Backend: web socket channel is made. name of the channel is securely randomly generated string(FOO). key(FOO) is stored in redis as Django-channels[redis] made a channel named that string(FOO). send the key(FOO) to user's browser.
browser: get the key(=channel name=FOO) and open the web socket channel(FOO). and also displays QR code(FOO).
user(smart phone): user launch smart phone app(already logged in). and scan the QR code(FOO). user smart phone app send a login acceptance request to the server with QR code's information(FOO)
Backend: server send securely generated login key(BAR) via web socket channel(FOO).
browser: get login key(BAR) via web socket channel(name is FOO) and redirect to login url with login key(BAR).
server: get the login key(BAR) and let the browser to log in as the user
login request key(FOO) could be a JWT(contains key, url, expire, etc..) or just secure string(varies depending on the scenario). it doesn't contains account information and server must store it.
login key(BAR) is usually a JWT. with JWT, it contains account information and server does not have to store the key.(stateless)

I think you wanna do something like WhatsApp’s web where the users log to the web app by QR code, if I was doing such implementation I’ll do it as follows.
When the user arrives to the login page, we create a logInSession with a random token and we save it to the database.
we send that random token to the browser, which will render QR code based on the random token. We start a pooling for ‘log_me_in’ view to check if the user scanned the barcode.
The user goes to the mobile app and select log-on browser activity which will launch the camera.
Once QR is read on the phone, make a request to the backend with the scanned token and update the logInSession with the username.
With the next call to ‘log_me_in’ view, log the user in based on the username and tell js to redirect to homepage.
Hope this is clear enough.

Related

Need Help to do Login authentication oauth2.0 while load testing

I have a BlazeMeter Pro account and I am stuck on the step I try to record in Jmeter and also try with BlazeMeter recording but not able to do it.
Now flow is I have to login into the system and perform the operation, we implement oAuh2.0 from the development side to authenticate the user from the Gmail and we face issue while record script that user is not able to authenticate to login when you hit with single or multiple users.
to authenticate I need all the below parameters and I have all details but now in Jmeter or BlazeMeter, I do not understand where I add all details.
client_id=
client_secret=
refresh_token=
grant_type=refresh_token
we are implementing a following steps at record time
Load a respective URL and open Gmail Login page
After Enter email and password page is redirect and particular website will be display
After enter user name and password on the website UI is display.
Please guide me on how I implement this and process my flow for load testing.
As per Google documentation in OAuth 2.0 for Client-side Web Applications you need to
Send a request to https://accounts.google.com/o/oauth2/v2/auth with:
client_id
redirect_uri
response_type
scope
parameters.
This request you should be able to record using your favourite recording option.
In your case you need to change this redirect_uri to some web server which you control as you will receive the token there in form of https://your_redirect_url_here/callback#access_token=your_token_will_be_here&token_type=Bearer&expires_in=3600
It's a good idea to use HTTP Mirror Server for this purpose.
Once you get the token you will be able to add HTTP Header Manager and configure it to send Authorization header with the value of Bearer ${your_token}
More information:
OAuth 2.0 Documentation
OAuth 2.0 Playground (if your application uses different flow you can replicate it there and see relevant requests/responses which can be later on implemented in JMeter)

DocuSign Implementation with my application

I want to integrate DocuSign with my application. There is no recipient.
The user who is signing in my application should sign the document which is generated through my application. After signing the documents through DocuSign, the user should be returned back to my application.
I don't want any email authentication.
How can I do that?
Yes, no problem! Use the embedded signing option. See the recipe.
This enables your app to provide the following flow:
The user logs in to your app
Your app logs into DocuSign using an admin login for your DocuSign account. The login is done from your app to DocuSign. Your app's user does not login to DocuSign.
Create the pdf (or other file type)
Your app sends it to DocuSign using embedded signing. Your app receives back a specific url to enable the user to sign.
Re-direct user's browser to DocuSign by using the specific url.
User signs
User's browser is re-directed back to your app
Your app can download the signed document if you wish
Also: Mobile devices are fully supported, including signing via the touch screen. Do not use an iFrame if your users will use mobile devices.

Django REST Backend for mobile app with Facebook login

I have to implement a REST backend for mobile applications.
I will have to use Django REST Framework.
Among the features that I need to implement there will be the registration user and login.
Through the mobile application the user can create an account using ONLY the Facebook login.
Then, the application will take the information from Facebook using the token-facebook and it will send this data to my server.
I tried using python_social about Facebook authentication and user registration using the Facebook token.
At this point I have doubts:
think there could be two choices:
1:
The mobile application use the Facebook-login to retrieve user data and will send a request to my server to create a new user with the Facebook data user and passing the Facebook-token.
In this case, in the server side, it will not be integrated python_social and facebook-token is a simple profile field.
Doubts: how can you implement the next login (which password Is necessary to use?)
2:
The second possibility is to use python_social. In this way there are no problems for subsequent logins. The token Facebook will be used to retrieve the data (and validate the user) by calling: do_auth
But in this case, for each user, the server will have to make a request to Facebbok (which actually is possible to avoid: the mobile application has already recovered all the data)
What is the best case? What do you usually use for authentication backend rest with Facebook?
i didn't unerstand the first case, when you are using facebook login it does the authentication and we will register the user with the access token provided by facebook. When ever user log in we are not worried about the password, authentication is not done on our end. so when ever user tries to login it contacts facebook if everything goes good there, it will give you a token with that user can login.

WSO2 Identity Server Basics - Making it Work

I'm new to the SSO world and I've recently installed WSO2 Identity Server 5.0 and done my best to hook in a service provider but I just can't seem to figure out how to make SSO happen.
Here is my current situation and goal:
I have a MojoPortal website where a user can log in. From there, the user can click a link to our FTP site powered by GoAnywhere. We want the user to be logged into the FTP site just by clicking the link instead of having to log in to it as well. The FTP site is SAML2 enabled so I chose the WSO2 ID Server to give SSO capabality between my mojoPortal and goAnywhere sites.
Here is what I think needs to happen - sanity checks welcome:
1. User clicks to access the FTP website and my mojoPortal website needs to create a SAML request and send it to the ID server. I can't seem to get a grip on doing this from an ASP.NET page.
2. ID server gets the request and validates it (you can test the request in the "SAML Request Validator" tool in the WSO2 console, right?)
3. ID server sends a response to the GoAnywhere FTP site which can be simulated with the SAML Response Builder tool in the ID server console.
4. The FTP sites says either OK or NO to access.
5. Not sure what happens next - how does the user get redirected to the FTP site.
So I have big issues: I don't understand the flow in great enough detail and I'm also having difficulties in getting the technologies to work together.
Any comments / help at all are greatly apprciated!
MojoPortal website - is this SAML2 Web Browser based SSO supported? If yes, then the solutions is clear.
You just have to register your 2 sites in WSO2 IS as SPs.
Then what will happen is , once the user log-in to the MojoPortal website, he user will have a live login session, therefore once he clicks on the FTP site, he will be able to access it without having to log-in again.
Hope this clarifies your doubts.

It is possible (and/or a good idea) to reuse OAuth tokens between apps?

I'm working on an iPhone app that uses xAuth to login to Twitter. The app also communicates with my own web service. Rather than maintain a user model inside the web service, I'd like to just allow anyone who's already authenticated via Twitter to make requests.
The high-level use case is this: the user logs into and interacts with Twitter through the app. They can also interact with my web service through the app. The web service itself never interacts with Twitter. Instead of maintaining a separate authentication system on my side, I'd like the server to say "OK, if Twitter says you're #joshfrench then you can have access."
I'm not sure how I should validate requests on the server side, though. How would I pass some proof of authentication from the mobile client to my web service? Can I send along the existing Twitter token and verify it from the server? Or somehow sign the request with my Twitter app's credentials? Is this even a valid use of OAuth?
If you store your twitter app key and secret on both he iphone app and your server, and then somehow transmit the user's oauth token (also called "access token") key/secret from the iphone app to the server, then you can do the same type of api calls from the server.
consumer = OAuth::Consumer.new(app_key, app_secret, …)
access_token = OAuth::AccessToken.new(consumer, user_key, user_secret)
response = access_token.get('/stuff.xml')
So, is it Okay to transmit that info from the app to the server? If you do it securely, and it's within the user's expectation for how the app behaves, then it's a perfectly fine use of oauth.
It's possible that it's not allowed by Twitter's terms of service -- I could imagine there being something that says you can't transfer a user's access secret across the network, or some such thing. (total wild speculation, I don't think it's particularly likely that that's the case)