I see that there's a row for each user in the "Authentication" section of Firestore with their data. Am I able to query for users in this table and add columns, or to create a new collection of users with a one-to-one mapping from user in the authentication section to user in the collection? If it's the latter, is there any way to both create a new user account and create the corresponding document in the collection as part of a single transaction?
Firestore doesn't have an "Authentication" section. Firestore only lets you read and write data into its database. Firebase Authentication is a different product that keeps track of logged in users in a way that's completely separate from Firestore. You can't query users in Firebase Authentication using Firestore. In fact, you also can't even query Authentication using the mobile client libraries (because that would be a possible security hole for your app).
If you want to query for all users in your app, you're going to have to do perhaps arrange for each user to write a document in some collection in Firestore that can be queried by Firestore client libraries.
You can use Cloud Functions with Admin SDK. Make a http endpoint or a http Callable that queries at admin.auth. But this is not a secure. The best way to do that is registering a firestore docuement whenever user is created using functions.auth.user().onCreate
Related
i am making a set of applications that share a common oidc provider (in my control), where the users will be created.
One of my applications is a stateless SPA "meeting" app where you can schedule meetings with other users, and you login purely by an OIDC token.
I am having a hard time thinking a strategy about the following
Should the "user" details be stored in the meeting app after a login? So let's say user A exists in the provider, then enters the meeting app. Should i save user A in the meeting app DB?
How to handle change of user details? Let's say user A changes name to User B in the provider. Until he logs in again, all the other users see him as User A still in the "contacts" list. What is the usual practice for solving this?
How to handle deletions in the provider. I need someway to signal that "deleted in provider -> deleted in app". Should i constantly poll the provider and get any missing users, create a push system, or is this just unneeded?
Thanks a lot in advance
That's actually a very good question and rarely explained well in online articles. Hopefully the below detailed notes help you with your solution. I have answered your questions at the end.
OAUTH USER DATA
Typically the core user data such as name, email etc belongs in the Authorization Server. It contains Personally Identifiable Information (PII) and changes are audited there. This is explored in further detail in the Privacy and GDPR article.
DOMAIN SPECIFIC USER DATA
This might include fields like a user's application preferences, and you may end up with data similar to this in your APIs:
Field
Description
id
A database surrogate key for the user
subject
The subject claim from an OAuth access token, which is typically a GUID or something similar
archived
A boolean flag set to true when a user is active in the app
field 1
A domain specific value
field 2
A domain specific value
To get OAuth user data within your applications your APIs can call the Authorization Server's SCIM 2.0 endpoint as described in this User Management article.
AUTHORIZATION AND ROLES
Interestingly, roles and application specific rights could be stored in either of the above data sources. You may want to start by putting roles in the OAuth data, but for cases where they are very domain specific and change often, I have found that storing them in my own API data works best.
DOMAIN SPECIFIC USER DATA AND ACCESS TOKENS
Sometimes you need to include domain specific user data (which might include roles) in access tokens. This Claims Article explains how claims can be looked up from external APIs during token issuance. This typically involves a REST call from the Authorization Server to one or more APIs, providing the subject value for which tokens will be issued.
CONSISTENT USER IDENTITY IN YOUR APPS
A user can potentially authenticate in multiple ways, such as default password / corporate login / social login. You may need to use some custom Account Linking logic to ensure that the subject field in the access token gets the same value in all cases. This prevents you ever creating duplicate users within your application.
USER INFO CHANGES
These are typically made by end users within an application screen, and your APIs then call SCIM endpoints to update the core OAuth data. A common case is when a user changes their name and / or email, eg if the user gets married. Note that the subject value remains the same after this edit.
USER ADMINISTRATION
In scenarios where corporate assets are used, an administrator typically provisions users, either individually or in bulk. This can be done via the SCIM endpoint. In some cases administrator actions may need to save data to both data sources - eg to create a user and set roles + application preferences.
USER INFO EVENTS
Sometimes your application needs to know about a user info event, such as new, deleted or changed users. This can be managed via Event Listeners, where an extension to the Authorization Server calls back your domain specific APIs when a user edit occurs. When a user is deleted in the OAuth user data you might then update the user's application state to archived.
DATA MIGRATIONS
Finally it is worth mentioning that the above also supports migrating to an OAuth architecture or between providers:
Get a combined view of the user data before migration
Insert all existing users into the new OAuth system via SCIM
Update the combined view of the user data with new subject values
Update your domain specific data with new subject values
SUMMARY
So to answer your questions:
Aim to avoid this because it adds complexity, though in some cases you may need to denormalise for performance reasons. The OAuth user data should remain the source of truth and the only place where edits occur to PII data.
Your meeting app would need to join on the OAuth user data and domain specific user data and present a list. This would probably involve caching a combined view of the user data.
See Administrator Events above. Your API should be informed of OAuth user data changes via an event, then your SPA would get current data on the next refresh.
When implemented like this you end up with simple code and a well defined architecture. Some providers may not provide all of these features though, in which case you may need an alternative approach to some areas.
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.
Imagine we have an application that is implemented based-on restFul and OAuth2, and also of course we've stored the user's roles and permissions in the back-end which is implemented by Java and spring boot. So I want to know how can we handle the permissions of users in the front-end. Indeed, there are some fields or columns that should be shown to the user who has specific permission or role but other users can see limited fields or columns.
What is the most efficient and sensible solution to this situation?
Should the front-end fetch available field or columns from the back-end?
Should the front-end has all of the information about user credentials to decide?
or is there any solution to do this?
Here is the most common solution, where all security is enforced by the API:
API responses omit fields / columns that the user is not authorized to access
UI can ask the API which fields / columns the user is authorized to access
UI hides elements based on this API metadata
It is common to have an endpoint such as this, which the UI can send an access token to in order to get the above metadata:
GET /api/userclaims/current
Currently using Auth0 for my application. In Auth0 we are storing the device_ids passed when a user logs in. Using an Auth0 rule, I am currently storing the user_id and other information in a DynamoDB table. I would like to include an array of the devices associated with a user. I have been unable to find how to access that data in the Auth0 docs. Anyone aware of how to do this?
I'm new to Piranha CMS and just trying to get my head around it. I'm using the MVC implementation and I need to do the following:
I need to extend the User with a property that stores an account number.
I need a page that is only accessible once the user logs in
On this page, I need to call a REST API on another server, using the account number a parameter, to retrieve a list of documents that the user has stored on this server.
When the user clicks the document, it will be downloaded as a PDF using the REST API once again
I just need general guidance on how to do this. How do I store the account number against the user (and manage this) and do I need to create a new Region that will show the list of documents from the remote server. Is there an example of creating a new Region anywhere and maybe returning a list from SQL that I can adapt?
Any help gratefully received.
Thanks in advance
Mike
The easiest way is to implement an extension with your custom fields that you attach to the user where you store this information.
When editing a page, go in under "settings" and select which groups should have access to your page. For this purpose I suggest creating a new group for site users that are not admins.
This should be easily implemented in either the controller or model for your page. When the user is logged in "User.Identity.Name" is the user id. Get the user, load the extensions & use the account number.
See number three.
Regards