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.
Related
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?
I'm looking to create a game server backend for a game I'm creating. We're currently using Firebase for handling of data and ads, and Firebase has built in authentication. Is it possible to have a user log into our app via Firebase's auth system, then confirm the user's authentication when they connect to the game server to ensure it's who they say they are?
Basically, after someone logs into our firebase, can we use that authentication information for a separate server, and what protocol/method would need to be used (if there's a specific one)
I've figured out the two steps you need to get the information required to auth, one clientside and one serverside. Note: the following examples are for the Java apis, but you can use any of firebase's equivalents.
Clientside: In the Firebase-Auth package, there's the FirebaseUser object. This contains information about their auth state, unique details, etc. There is a method here called getToken(), which will grab your token for the current authentication. Once you have this, you want to send it to the server when you need to auth.
Serverside: On the server, there's a FirebaseAuth object. Once you get the token from the client, you can use verifyIdToken(), which will confirm this is a valid token and give you the details about the user when you get the result. I suggest cross-checking the UUID against one a client sends, to just confirm someone didn't get their hands on a token and send a random ID.
Hope this helps.
I'm currently using Google authentication provided by Firebase, but I need to generate a unique id for each client connected to Firebase, i.e. even if user is logged in with the same Google account on 2 different devices, I'd like to have a different id in auth object.
I want to do WebRTC signaling over Firebase and I need to be able to uniquely identify a device (even if a user is logged in with the same account on all of them). I also would like to have this id in auth object, so that I can use it in security rules to define that e.g. only given device can read messages sent to it.
Is it possible to do it without custom authentication and generating JWT token on the server? I'd like to add more providers in the future, so I'd really like to avoid handling it myself.
Not without custom auth. – Frank van Puffelen
I have a SaaS which integrates with SalesForce. I have synced all the SF users to my database so that my local users have a SF user ID stored.
I need to have a custom link in SF which will bring the user to my site and log them in automatically. The wrong way to do this is to pass the SF user ID in the link and simply match the SF User ID to the one I've stored in the database. What is the right way to ensure the referred SF user should be authorized? Is there some token I can put in the link from SF that I can then verify against the SF API?
There are two approaches for this:
Create a canvas app that sends a signed request to your site. The signed request will include the current users session details. You can use these to verify that the user is indeed who they say they are. I.e. They haven't just made up an id and that they came from an active Salesforce session. See Verifying and Decoding a Signed Request. The advantage of this approach is that you can verify the request has been signed with your apps consumer secret.
Its an older approach that isn't really promoted by Salesforce any more as the canvas apps superseded it. Create what was known as a composite app. This was basically an iframe to your external site that could include the session id and server url in the query string (over SSL). With these details you could call back into Salesforce and get the User Id of the session owner.
Incidentally, the Salesforce StackExchange site is a great place to ask Salesforce specific questions.
Is there a good way to do secret key authentication for http queries from a salesforce app to my own web server? In other words, I'd like to give each company that installs our application their own secret key. Then each http call the app makes to our server (whether json or just a link to a hosted iframe) would look something like this:
groupid = groupid
param1 = value1
param2 = value2
signParam = signValue
Where signValue = md5("groupid=groupid,param1=value1,param2=value2,secretKey"
Then when I receive the query, I calculate the signature as well to make sure it matches before I perform any actions on our web server. The problem is, I don't see how I can assign and store the secret key for each company that installs our app (that is, have them store the secret key in their installation).
Is there a good way to do this that I'm missing? And if this isn't possible in salesforce, how else do you authenticate web queries before you perform actions in your own server?
Rather than trying to track it on the salesforce side, have the salesforce side send the users sessionId to your webservice, you can then use the API to validate that sessionId get details about the user, and check locally that the particular user/organization is licensed. There's some articles on the developerforce wiki about using this approach.