We're planning to use IDaaS for better identity management. We are comparing functionalities between Okta, Auth0, and AWS Cognito.
However, Facebook provides a way to refresh user token. They also have an option for extending page token. My question is if I use any of IDaaS or identity management system, can I use those functionalities.
I know I can get a refresh token from Okta or Auth0 and use it to get access token. But could not find any way to retrieve or use the refresh token from Facebook. Am I missing anything?
I have added Facebook as Social Identity Provider. I can log in using via facebook account. My applications do not know about Facebook's App Id and secret. Is it possible to use the facebooks refresh token functionalities via IDaaS?
you can use Okta's Identity Provider API to get the Facebook access token issued for a user during authentication.
https://developer.okta.com/docs/api/resources/idps#identity-provider-social-authentication-token-model
You can then use it to call Facebook APIs to get a refresh token that you can then store within Okta as a custom attribute on the (idp)user profile.
I'm assuming that you want to use the FB refresh/access token to get additional data from Facebook. Is that your use case, or is it primarily about keeping the user logged in to facebook? More detail on the use case can help me provide more relevant information.
Related
is it possible to use AWS Cognito that has a custom authentication flow enabled, while also using an external identity provider like Facebook or Google? I've tried this with Facebook and the Cognito Hosted UI, but my DefineAuthChallenge-trigger was not hit.
I contacted AWS Support and they pointed me to the Cognito documentation here where a note says that
The Amazon Cognito hosted sign-in web page does not support the custom authentication flow.
As an alternative, this solution was proposed:
Alternatively, if you would like to use custom authentication flow with an external identity provider, you will have to write your own custom login flow using one of Cognito's SDKs and use Facebook as a way of login.
My idea is that you can probably do this by defining a custom challenge, that asks, which identity provider you want to use, as the first, initial challenge. If Cognito is chosen, the user needs to provide their SRP-stuff or username and password, if that is enabled. If Facebook is chosen for example, you would probably need to send an auth challenge to the client saying that you want a token or code from them, which can only be gotten, if the client shows the website with the Facebook login. The challenge response to the server would then be the gotten auth token from Facebook or code or some other answer that the server can then use to authenticate the user within Cognito, where the Facebook app is connected and is registered as an external identity provider
This is my idea of how I would go about to do this, but I haven't actually implemented this. I hope this helps someone trying to do this though.
This is not exactly a problem; rather I would like to clarify Firebase authentication.
I build an Angular app and I use Firebase Authentication to sign in via Facebook (later with other providers too). Everything works fine. However, I need to verify access token. Since I get two tokens, one from Facebook and one from Firebase, should I verify both? Or verifying Firebase IdToken is enough?
Does Firebase "verify" Facebook (and other providers) access token?
Firebase Auth will verify the Facebook access token before they complete sign-in for that user and mint an ID token for that user. It is the whole point of using Firebase Auth. You don't need to manage different providers and their intricacies. They do it for you. You just get one standard credential (ID token) regardless of the underlying provider. You only need to verify that ID token.
You get the verification for free (they verify under the hood) with other Firebase Services (RTDB, Firestore, Storage). If you are using your own server, you can use Firebase Admin SDK to verify the token.
I get it that Oauth is used to grant permission to a third party application to access a user's data (like photos on his facebook account) without revelaing his facebook credentials to the third party application. For example, when you try to use an online photo editing tool and you want to load a photo from facebook, facebook will pop up a message asking whether you really want to allow the application to access your data. So at that point facebook just returns a temporary access token and the app can use it to access your facebook photos. (as i understand the scope for this access token is such that it only has permission to access the particular user's photos only) Yes, this sort of a setup is required because you can't trust a third party application that much as to give away your credentials.
Assume somehow instead of oauth, facebook used api key authentication. This would mean that all third party applications that have subscribed for facebook API already have a key which they can use to access facebook's data sources.So that the app can directly take you to your facebook photos and facebook will not notify you that an outsider is trying to access your private data. This approach is not suitable for an api that exposes user sensitive data but for apis that expose not so user specific (like google maps) data, the api key approach should be enough, right ?
So my question is, what are the criterion to decide which authentication type should be used ? And appreciate feedback if my understanding is wrong.
Here are 2 of the standard 4 Oauth2 flows which cater for the scenarios you mention.
Authorisation Code
Client Credentials.
Using your Facebook example above you could think of like this:
Use Authorisation Code flow for your "Oauth" scenario, where your app needs delegated authorisation to access a user's Facebook photos. This means the user must login and grant access to your app and your app must have an API key (client ID) issued by Facebook.
Use the client credentials flow for your "API Key" scenario. This would be when your app needs access to, for example, public Facebook pages / info and thus does not require specific user consent and can just use its API Key (Client Id & Client Secret)
I need to login users via Instagram for my mobile application so I can make calls to Instagram API and get some information from the Instagram. Simply, my application will ask user to authorize Instagram access and able to get access token for API calls. Application should not ask user to login again once the user is authorized. I already setup my Instagram client-app to implement server-side authentication flow.
My challenge is I want to do this on by using AWS mobile services. I already setup custom authentication from MobileHub and came to point where I need to define my custom authentication flow (in this case it is Instagram authentication flow). Under AWS Cognito app when I go to Triggers tab, I see different options for defining lambda functions associated with my authentication (such as pre/post auth or define / create / verify auth challenge). I am not sure how to align Instagram Authentication flow with these functions. Or should I use something else. Also I am not clear how does AWS Cognito manages authentication flow: I don't want my users to go through authorization process every time they start my application. I believe AWS Cognito link users from my custom flow to some Cognito identity and able to authenticate when they use my application. I really appreciate any suggestions, or even code sample (if available).
Check this Document for Cognito Identity. Instagram is not there by default. So you have to use External Identity Provider, most probably using Open ID Connect Providers.
I have a website where I was allowing user logins based on my own database. I have migrated this login system to Google+ sign-in and it worked well for UI based login workflow.
My website also allows users to perform some operations through our custom REST API. I want my API users to go through google sign-in as well. Does google provide a standard workflow where our end-users authenticate themselves from google and send auth token to my API?
If there is no standard workflow defined by google, I have thought of hack-ish way where users use google refresh token as API key. I will not store refresh token in DB, rather Users will send the refresh key to my API in form of API access key. API will generate access token from google. Users will use the access token as session key for further requests (for abt 1 Hr). Is it right way to go forward? Is there any security flaw in this?