I wonder if anyone can help. I'm trying to plan the AWS services that I'll need, and how they hang together, for a web application I'm planning.
Specifically I'm thinking about the user registration and login process using Cognito and DynamoDB.
Users will need to be registered and logged in in order to perform some actions. I'm thinking serverless, so these actions will be Lambda functions fronted by API Gateway. As with many websites, I'd like to use Facebook as the user authentication model. I'm thinking I need:
To create a Facebook application
To configure Cognito Federated Identities with the Facebook app id
To have a DynamoDB table to contain user information
To provide a facility to allow a user to register using their Facebook identity
On registration, create a record in the DynamoDB user info table with user's name, email etc as taken from their Facebook profile
To provide a facility for registered users to login with their Facebook identity
To somehow pass the user token (JWT token ?) on subsequent client requests to API Gateway endpoints
So far I've created the Facebook app and have an application ID. I've created the Cognito Federated Identity for the app and configured it with my Facebook app id. And I have set the Authorisation field for the Method Request for the API Gateway to "AWS_IAM"
Using the Facebook javascript SDK and the AWS javascript SDK, I've put together a very basic page that allows login via Facebook, then creates a new AWS.CognitoIdentityCredentials object with the facebook authResponse accessToken. Lastly it calls AWS.config.credentials.get to get the Cognito credentials. But this isn't really the steps above - it just proves that a user can login with their Facebook id and I can pass it to Cognito.
My specific questions therefore are:
What I'm trying to work out is how to do registration. Once the user has logged in via Facebook, how can I create a user record in DynamoDB?
And likewise, when a user goes to login (rather than register), once the user has logged in via Facebook, how can I ensure they have a user record in DynamoDB? (because if they dont have a record, then presumably they've not registered)
Lastly, how can I pass the user id / token from the client to an API Gateway endpoint?
I'm not looking for code samples etc - just pointers as to whether I'm thinking along the right lines or barking up the wrong tree. A high level of how the various components need to hang together would be great, as would any links or references to similar ideas of concepts.
Thanks
Related
In Firebase, it is possible to log in a user as anonymous with a token, and when the user decides to register, just update the credentials. I have a hard time understanding whether the same is possible with Auth0.
We are now using Auth0 as identity provider, the flow is the following:
The user is using the app anonymously with limited access.
User registers in the app with Auth0.
Auth0 issues a token
Firebase receives the token and lets the user use the restricted parts. All the data generated by the anonymous user is lost
What I want to achieve:
When the user starts using the app, Auth0 immediately creates a user token
The token is valid to access certain parts of Firebase database
If/when the user decides to register, their token remains valid but receives additional credentials
Firebase lets the user use the restricted parts
It's Konrad from Auth0 Community Team. Yep as Baskaro said unfortunately it's not supported from our side of stack. It will be great if you can submit it as a feature request to our product team using our feedback form (you will be contacted by one of our product managers within 10 business days):
https://auth0.com/feedback
I'm using .NET backend on Azure Mobile Service. It's easy to set up authentication with social identity provider, so that the client can use e.g. Facebook iOS SDK to login, as illustrated in the official tutorial
In custom authentication, as I need to maintain my own Account table according to the official tutorial, I have full control over the registration & login.
I'd like to have a centralized User table to store information about all users, no matter which channel they used to authenticate.
My question is, is there a way for the .NET backend to be notified when a user register or login with a Facebook token? So that a new row can be added to the centralized User table even when the user is using Facebook to authenticate?
Thank you!
Yes - the User.GetIdentities() method contains the token and mechanism that was used to authenticate the user. You can use this to update your table. For an overview of how to use this token, see this blog post by the team: https://azure.microsoft.com/en-us/blog/custom-login-scopes-single-sign-on-new-asp-net-web-api-updates-to-the-azure-mobile-services-net-backend/
I'm using Wordpress + WooCommerce in combination with the WP-API as a backend for my mobile ecommerce App.
My goal is to offer some social login (via Facebook, Twitter, Google etc.) within the app to register/login and then use the WooCommerce API to receive e.g. all the orders of that authenticated user.
Currently my plan is:
Use some client SDK so that the user e.g. can login using his FB account
From step 1 I get e.g. the users name, email and FB ID which is sent to a custom endpoint for adding the user to the Wordpress DB (like https://github.com/royboy789/wp-api-social-login)
Create a custom endpoint for orders with WP-API (e.g.: .../orders)
Inside the endpoint function check wether the user is authenticated
If user is authenticated, the endpoint returns the user's orders using a WooCommerce API wrapper
(https://github.com/kloon/WooCommerce-REST-API-Client-Library)
But I'm struggling at #3 because I don't really know how to check wether the user is authenticated.
I thought about creating another endpoint that will contact the OAuth authorization server to check the user’s credentials using e.g. Facebook's access token. And if the check is valid, I would create a custom Access Token for my API using some hashing of the userID, email etc. which is sent back to the client app. Then this Access Token is used for every call to my API which then reads out the User ID from the hashed token and returns e.g. all the orders for this User.
But somehow this feels just not right. Especially because this way I'd create an endless living Access Token...
Once you have done #2, the HTTP response from WP will include the auth cookie: see https://github.com/royboy789/wp-api-social-login/blob/master/inc/social-routes.php#L31 in the sample pointed to by the question.
Not sure what HTTP library you are using in the app but if you save the cookies received in the response and just reuse them in all subsequent requests to the server then authentication should be taken care of: you won't need an extra check/access point, as the login/registration automatically logs the user in, and the standard WP cookie checks take care of the verification on new requests.
I am currently using firebase to make an ionic app. I am using firebase simple login for social auth (facebook, twitter, email & password). The auth works perfectly, it $broadcasts the authed user. However it doesn't seem to create a user in the actual firebase db. I was wondering how I can get the users that have been authed using my app.
For most of the authentication protocols it supports, Firebase doesn't store user data anywhere. Even for the protocols where it does store data (I only know of email+password doing this), it stores this information in a place that your application can't access (though you can find those users in the dashboard of your Firebase).
To quote the Firebase documentation:
It does not store profile or user state in your Firebase. To persist user data you must save it to your Firebase.
What most applications end up doing, is keeping a list of users inside their Firebase that they manage themselves. So when a user first authenticates with the application, it creates a node under /users/<uid> that contains the information for that user.
See this section of the Firebase documentation that describes storing user data.
Firebase does not store profile or user state in your Firebase instance. To persist user data you must save it to your Firebase.
Firebase provides multiple authentications services
Using existing social login providers such Facebook, Twitter, Google, and GitHub. Using these services provides an option for your users to access your application without creating a new account.
Using built-in support for logging in with email & password. This requires registration and account creation that is handled by Firebase. The user account information is stored outside you application.
Using a custom authentication to implement existing server-side authentication, single sign-on, legacy systems, or third-party OAuth based services (such as Yahoo).
Once authenticated, Firebase return a variable auth to your application that you can use for authorization and access control. This variable is null for unauthenticated users, but for authenticated users it is an object containing the user's unique (auth.uid) and potentially other data about the user.
If you want to persist additional user information such as name
and location, then you need to use auth.uid and store it in your
Firebase with additional profile data.
Internally, Firebase generates JSON Web Tokens (JWTs) and creates authenticated sessions by calling Firebase.loginWithCustomToken() with those tokens. Each user is assigned a uid (a unique ID), which is guaranteed to be distinct across all providers, and to never change for a specific authenticated user.
The user data for firebase authentication is stored in firebaseLocalStorageDb in IndexedDB. After login to website, if you delete firebaseLocalStorageDb, the login user data for firebase authentication is all deleted so you need to log in website again.
If I create a new product, use simple auth, there is a "create user" API. How do I restrict it so that only invited emails (either by the email or via a one-time key) can sign up? Doesn't seem to fit easily into the rules, but I am probably missing something.
First, I should point out that the core Firebase API uses JSON Web Tokens for auth, which you can generate yourself, so you have full control over the creation of user accounts and can restrict it however you like:
https://www.firebase.com/docs/security/custom-login.html
I'm guessing you're referring to our Simple Login service.
Simple Login is a service that provides some common login options. It has no way to restrict creation of new accounts. However, you can restrict what those accounts can do with Firebase. For example, you could set your security rules up so that only user accounts in some authorized list (in Firebase) are actually able to read or write data.