org-a-m1-app, m1-client-id, m1-client-secret
org-a-m2-app, m2-client-id, m2-client-secret
org-b-m3-app, m3-client-id, m3-client-secret
org-b-m4-app, m4-client-id, m4-client-secret
Can I use client id + secret credentials for an app to uniquely identify a machine?
Can I use client id + secret credentials from m1 and access the service from m2?
How to associate all the above machines as belonging to a certain organization?
Related
I am making an app with firebase that should allow a user to authenticate their identity when they get to a certain physical place in order to be let into the place. I want staff at the place to be able to use their own phones to securely verify the user's identity and let them in.
My first idea was to make the user's phone present a QR code with the uid of the user for the designated staff members to scan. The problem with that is that the uid is not a valid means of authorization in firebase because it is not a secret, which makes me worry that this approach may not be secure.
Is there any secure way for one phone to authenticate the identity of a user who is logged in on another phone?
EDIT: My question has nothing to do with logging in to the same user account using multiple authentication methods, it is about using a physical device connected to one user account to authenticate that a different physical device is connected to a different user account.
I have a SaaS application that has multiple organisations and each organisation has multiple users. Each customer is an organisation (not a user) and the customer wants access to their data in my SaaS application via API. Obviously I need to authenticate the customer so they only receive the data that belongs to their organisation.
The customer will be importing this data from their application so this is a server-to-server API call which I assume I need to use client credentials flow.
The customer will be able to generate the credentials on a self-service basis.
Is using client credentials flow the correct flow?
If using client credentials flow does each customer have their own client_id and client_secret or does my application have 1 client_id and each customer have their own client_secret?
The standard solution for this type of B2B API solution is to use Client Credentials flow as you suggest.
Each business parter uses their own client id for identification when calling your API
Each partner is also given a string client secret - though it may be possible if your authorization server supports it to use secrets based on an X509 credential
Use of different client ids enables you to turn off Partner A without impacting PArtner B - and also to tell callers apart
Authentication completes based on the client id and secret being verified and you then move onto authorization. Typically your API will need to continue by doing this:
Receive a technical client id such as 08134scdv79
Map it to an application specific id, such as a primary key from your Partners database table
Authorize the request based on whether the caller is allowed to get the data requested
The one interesting aspect to your question is the self service part. I assume you mean some kind of administrator from a business partner can set up credentials - but that this remains a restricted operation?
We are in the middle of doing some updates to Cognito for an already in use system. If possible, I'd like to keep the current client IDs and keys the same so that we don't have to go update all the device clients.
Is there a way to manually set client ID and key in AWS Cognito? I was unable to find documentation supporting this.
Unfortunately, Cognito does not provide us the ability to set our own app client IDs or secrets. They are both auto-generated.
If you are constantly running into cases where you need to re-create your app client, I would recommend creating an endpoint to retrieve app client information for your applications given the app client name which can be set by you upon creating of the app client.
You can achieve this through a combination of Cognito APIs.
Use DescribeUserPoolDomain to obtain the UserPoolId given the Cognito domain.
Use ListUserPoolClients to obtain all the App Clients given the UserPoolId. This will give you a list of pairs (ClientName, ClientId). He're you will be able to get the ClientId corresponding to the ClientName you set originally.
Use DescribeUserPoolClient to obtain the App Client Secret given the ClientId and UserPoolId.
I have built a Room Booking application in FileMaker that accesses Google Calendar via the Calendar API, authenticated with OAuth2.
Everything works well except I am unsure as to the relationship between the OAuth2 Client token flow and the individual FileMaker/GCal users who will use the system.
At the moment, I am both the owner of the project in the Google Developer Console, and the only beta tester, so naturally the system works with my calendar - I log in once, pass OAuth2 my ClientID and Secret, generate my Code, swap it for the Token and Refresh and I'm off.
However, the whole system at the moment only has one Token and Refresh, held in a single row FileMaker table, thus, when I create a second test user, things still forward to my Calendar.
This is where I am unclear. It sounds obvious, but it's hard to find a clear answer on this.
Should I have it so each user uses the same ClientID and Secret (which I keep secret from them) to generate their own unique set of Tokens?
Or is the single set enough, and I'm misunderstanding some other aspect of the system (and if so, what)?
In short: are the Tokens per Application or per User of the Application?
Answering my own question:
CLIENT'S (= Application) STUFF
Client ID: pertains to the Application, general to all users
Client Secret: pertains to the Application, general to all users
Redirect URI: pertains to the Application, general to all users
USER'S STUFF
Authorisation Code: specific to each user, requires the Client ID and Client Secret, and retrieved as a GET variable from the Redirect URL following user's authentication with the 3rd party service (e.g. http://YourRedirectURI.com?code=abc123)
Refresh Token: specific to each user, requires the Client ID and Authorisation Code
Access Token: specific to each user, requires the Client ID and Refresh Token, and is time limited (typically 1 hour) so a new one needs to be regenerated once it expires
NB Users should not see the Client Secret (or ideally Client ID either). They should be used in the Application's internal logic to generate calls for the users' Code/Token but not seen by them.
OAUTH2 FLOW
So, essentially the OAuth2 'Flow' is as follows:
1) Your Client ID + your Client Secret + their authentication login to the 3rd party service = that specific user's Authentication Code as GET var in Redirect URI
2) Your Client ID + your Client Secret + their Authentication Code = Refresh Token & Access Token
3) Your Client ID + your Client Secret + their Refresh Token = new Access Token
I am starting to design Multi-tenant system and already read the article:
http://msdn.microsoft.com/en-us/library/aa479086.aspx
Any case, I have couple of question related to authentication.
For example, we need to support a customer that requires Separate Databases.
More precisely, the customer uses Separate LDAPs (LDAP per tenant).
The problem I can not solve that the authentication framework need to know a tenant before the authentication to authenticate against the appropriate LDAP.
How a user selects tenant during the authentication?
The form authentication:
Should we develop a special form login with 3 input fields: user name, password, and tenant?
Should we show to a user the list of all tenants?
This is information disclosure, a user can see the list of all tenants in the deployment.
Should it be free text filed? In this case it is error prone.
Other types of the authentications:
How tenant information can be send if we use Basic Authentication? Digest Authentication? Client Certificate Authentication?
Any point to already existing(free) frameworks will be appreciated.
As you correctly mentioned, You have to identify the Client/Tenant ID while you allow the user to login to the multi tenant application. There are basically 3 ways to identify the Tenant ID.
use company code text field where your users can enter their tenant id,password/username to authenticate (Error prone, users may not enter the id correctly).
collect the username and password and identify the Tenant ID by yourself, but you have enforce Unique identity (email) for all the users in the system. (Preferred)
Assign unique Sub-domain for each tenant (Preferred). using unique url of the customers, you can identify the tenant id and you can connect to appropriate DBs of the customer.
WRT to Authentication, I personally don't recommend Basic Authentication because of the security vulnerability, So you could either go with Digest Authentication/ Client Certificate Authentication.