Objective is to develop a React SPA (Express backend) that has a custom user registration form to collect additional data at the time of registration (such as 'first/last name', 'role', 'date of birth', 'address', 'telephone', 'consent to TOS / privacy policy', etc.). It needs to allow for both email/password and social logins.
I'd like to use Auth0. However, it seems that customization is limited. They encourage you to use the Universal Login, but it only allows customization of logo and colors. The #auth0/auth0-react package doesn't seem to have a sign-up function. The auth0-js package has the auth0.WebAuth class which has a signup function, in which additional fields can be stored in the 'user_metadata' object. There is a limit of only 10 properties.
What would be a considered the better practice to implement this?
Send all the fields (email, password, and additional fields) to my backend, and then have the backend (a) call the Auth0 Management API to create an account, (b) create a profile in my backend to store the additional fields and that links to the Auth0 'sub' field so that I can associate the profile with the user. This would avoid constantly retrieving user_metadata from Auth0.
Use auth0.webAuth and store the additional data in 'user_metadata' My backend would then have to call the Auth Management API to retrieve this data. I would also be limited by the max 10 properties in user_metadata.
Have the user signup, and if successful, redirect the user back to the SPA where the additional fields are entered and submitted to my backend for storage. This would violate the objective of collecting all of this information at the time of signup. I imagine this is the only approach that works when signing up with a social login.
Or is there another approach ?
Related
I have an interesting use case for you today.
My team and I are building a free, third party, calculator tool that enables users to calculate metrics using their store's data.
We are looking for ways to pull in the necessary data and perform the calculation to show users... so far the best we've come up with is asking the users to export a report from Shopify and upload it into our application.
Looking for a user experience similar to this:
User opens our tool, application is hosted on custom-domain.com
Somehow the user authenticates or logins in to Shopify, or approves our app temporary access to their data.
Our app performs the calculation for the user, ending data access
Any ideas as to how this authentication or access of data can be facilitated? Shopify doesn't seem to have a 'login with Google' kind of authentication button.
Thanks!
There are two modes for authenticated access, namely Online and Offline. What you need in this scenario is Online Access.
From Shopify Docs
Tokens with online access mode are linked to an individual user on a
store, where the access token's lifespan matches the lifespan of the
user's web session. This type of access mode is meant to be used when
a user is interacting with your app through the web, or when an app
must respect an individual user's permission level.This access mode
must be explicitly requested in the authorization phase.
It should also fulfill your needs related to ending data access.
An access token created with this access mode is temporary, and is guaranteed to expire after some amount of time.
When a user logs out of Shopify admin, all online mode access tokens created during the same web session are revoked.
Once you have the access token, you can use Shopify API to query data so that your users don't have to upload any files manually.
So I am having some trouble figuring out how to implement a sign-in for my app using google oauth. Every example I see shows how to authentication the user, get their permissions and then start using the Google APIs.
I do not care about permission or using Google APIs. All I want to do is have the user sign-in to my app using google oauth instead of having to implement my own authentication system with user and passwords in the database.
After the user authenticates with their google account, then they can change settings associated with their account for my app. What is the flow i need to implement to achieve this?
How would I associated a google user with certain data defined in my own app's database? I have successfully implemented the authentication part but then what would I need to store in my DB to associate them with their actions and data. Would I need to use sessions? and then retrieve their Google+ ID, save it in the database and then use that to identify them in the database for later when they log in again?
any help is appreciated
Once the the server validates the access token, a user account can be created in the database, saving the Google ID along other user details (ID, email, name etc).
If your application also supports normal registration, and an account is already present for that user (matching email), then you can just fill in the (nullable) Google ID column in order to link the account(s).
Suppose I started with an ASP.NET5 MVC6 webapp based on a default Visual Studio 2015 web application template with individual user accounts and Google+ (FB, LI) authentication enabled.
Then I created two signup pages, one for consumer users and one for professionals. I want the application to create consumer user accounts if users came from consumer signup page. And I want the app to create professional user accounts if users came from the professional signup page.
What should I do to customize the default solution?
pass role parameter to /Accounts/ExternalLogin, then somehow preserve it through OAuth process and fix user creation logic?
same but use cookies to pass role info?
or maybe have 2 copies of external login infrastructure - each responsible for its own account type?
Isn't is a common problem - how to pass additional information to the code responsible for account creation?
What should I do to customize the default solution?
Quite good explanation with examples:
ASP.NET 5 Documentation -> Authorization
I want ... create consumer user accounts ... and ... create professional user accounts...
In my opinion you can use (create) one account type for all (in common Db) and then during registration process you can assign additional properties to this account. You can use Roles or Claims, so this allows you to personalise user experience depends on 'account type' (using Authorisation).
If you just want have only customer/professional accounts, probably Role-Based Authorisation will be simpler to use, however Claims-Based Authorisation is little bit more elastic and will be beneficial in the future.
We're building a new application that will have a user signup and logged-in user area. Authenticated users will have access to our API.
I wanted to separate the user signup OData endpoint from the logged in/API-access OData endpoints.
For new-user signups, a separate in-network API works. However, public-facing, I'd like to know some proven architectural strategies.
I would bet that you could use FormsAuthentication to lock down access based on users and/or roles in your MVC application. OAuth could be used in conjunction to handoff the identifying info to your authentication/authorization routines.
Here is an article on using OData and FormsAuthentication.
I'm a person with a non-programming background working on a web application that must store user-generated content and always associate that content with the user who created it. I just had the developer tell me since the application must do this, using Facebook as an alternate login method is pointless because Facebook only let's a third-party web application hang on to Facebook profile information for a certain amount of time, and therefore users who login via Facebook cannot actually contribute content that would remain in the web application's databases.
I'm having trouble swallowing this. I just signed up and logged in to stackoverflow using my Facebook account, and it appears to have generated a site-specific user ID that was automatically associated with my Facebook account - thereby allowing me to save/store content on the site without having to actually create a site-specific profile.
My questions:
Where is the misunderstanding here? To what extent do alternative login options affect the ability of my application, which will consist largely of user-generated content, to store user-generated data and consistently associate it with that user? Appreciate the help!
Alternative login allows users to use an existing account to sign in to multiple websites, without needing to create new passwords. Alternate login using facebook, OpenID, gmail or any other provider doesn't affect the ability of your application to store user generated content.
When a user logs in using a login option for e.g. facebook, user enters the facebook login credential(if he isn't already logged in), facebook generates a authenticated token which is utilised by your application for future use.
In case of alternative logins only the login information (User ID/Password) isn't stored in your application, it totally depends on how you are implementing it in your application. But in any case it doesn't affect your application in saving storing and using the user generated content in your website.
Please refer to this link for more info -
http://openid.net/get-an-openid/what-is-openid/
http://oauth.net/
Hope this helps!