I use the Supabase database and I want to do authorization using a third-party service that is not in the list of supported, how can I do this?
Thanks for your query! Feel free to submit a Provider request on the Supabase Auth thread
We also support self hosting, so it's possible to fork and add the provider on your own copy of Supabase Auth - feel free to take a look at the PR adding Keycloak Auth for reference.
Hope this helps and let me know if there are further questions.
Jo
Related
I'm using Firebase in a side project that requires authentication using Facebook, Twitter, Google and Twitch. Unfortunately, Firebase Auth doesn't support authentication using Twitch out of the box. I would like to know the best approach to solve the problem: can I use Firebase Auth & a Custom Auth system only for Twitch?
Firebase supports signing in with any provider, as long as you are willing to write the code for it. The process is pretty well documented in a page called creating custom tokens.
If you're looking for samples for other providers, have a look at the functions-samples repo, which contains a.o. samples for signing in with LinkedIn, Okta, and Spotify.
I've setup an OIDC Connect App inside my OneLogin account and was already able to login different users using this client
https://github.com/IdentityModel/oidc-client-js
and the "implicit flow".
The oidc-client-js supports session management out of the box using the iFrame mechanic to poll the IDP (onelogin in my case) about the status of the users session.
https://brockallen.com/2016/08/12/check-session-support-in-oidc-client-js/
The OIDC client does not even start doing so since in my signin return data there is no "session_state" value, instead it is just undefined.
I was reading the OIDC specs about it
https://openid.net/specs/openid-connect-session-1_0.html
and from paragraph 2-5 there are all the things the IDP needs to offer in order to make session management work via OIDC.
Since I could not find anything in the OneLogin Docs, I would appreciate any hint, help, experiences with this specific
https://openid.net/specs/openid-connect-session-1_0.html:
2.1. OpenID Provider Discovery Metadata
These OpenID Provider Metadata parameters MUST be included in the
Server's discovery responses when Session Management and Discovery are
supported:
check_session_iframe ...
end_session_endpoint ...
I don't see these metadata parameters in the OneLogin discovery metadata, so it looks like Session Management is not supported.
I'm the product manager for OpenId Connect at OneLogin. The accepted answer is correct. We don't currently support the session management spec but are considering it as a future roadmap item.
Im new to backend dev, and I have a full fledge working React app that GETs,DELETEs and PUTs data using a fake server. Now I need to use an actual backend and I was thinking of going with Firebase as it seems really convenient. However I saw some examples using Firebase directly in the React app, and some using Node.js to do the work.. Could someone please tell me whats the best way to go with this? If there's an easier way to create REST API using express/mongo, I am also open to those :)
You have to keep in mind that anything you do from the frontend will be visible to the user, so communicating with Firebase from React will be a bad idea at least for anything involving sensitive information (passwords, credit card info, etc.). Just because you can do something doesn't mean you should. Use a Node backend and use that to communicate with your DB and other services.
To address the last part of your question, it is possible that Firebase might be more than you need. A simple setup with Express and MongoDB might be easier. MLab has a pretty good free sandbox database-as-a-service that requires very minimal setup.
I think firebase can also be a good fit, you can use Firebase auth to manage authentication and Rules in the Realtime database or in Firestore to prevent not authenticated users to manipulate your data https://firebase.google.com/docs/database/security/ And to get the best out of Firebase I would recommend using the SDKs but you can also use the REST API https://firebase.google.com/docs/reference/rest/database/
Also if you want to have functionality on the backend you can do so With Firebase Admin SDK https://firebase.google.com/docs/reference/admin/
From my point of view that is one of the advantages of firebase, you can get con going really fast without having to worry about managing infrastructure.
I'm working on a React-Redux web-app which integrates with AWS Cognito for user authentication/data storage and with the Shopify API so users can buy items through our site.
With both SDKs (Cognito, Shopify), I've run into an issue: Their core functionality attaches data behind the scenes to localStorage, requiring both SDKs to be run client-side.
But running this code entirely client-side means that the API tokens which both APIs require are completely insecure, such that someone could just grab them from my bundle and then authenticate/fill a cart/see inventory/whatever from anywhere (right?).
I wrote issues on both repos to point this out. Here's the more recent one, on Shopify. I've looked at similar questions on SO, but nothing I found addresses these custom SDKs/ingrained localStorage usage directly, and I'm starting to wonder if I'm missing/misunderstanding something about client-side security, so I figured I should just ask people who know more about this.
What I'm interested in is whether, abstractly, there's a good way to secure a client-side SDK like this. Some thoughts:
Originally, I tried to proxy all requests through the server, but then the localStorage functionality didn't work, and I had to fake it out post-request and add a whole bunch of code that the SDK is designed to take care of. This proved prohibitively difficult/messy, especially with Cognito.
I'm also considering creating a server-side endpoint that simply returns the credentials and blocks requests from outside the domain. In that case, the creds wouldn't be in the bundle, but wouldn't they be eventually scannable by someone on the site once that request for credentials has been made?
Is the idea that these secret keys don't actually need to be secure, because adding to a Shopify cart or registering a user with an application don't need to be secure actions? I'm just worried that I obviously don't know the full scope of actions that a user could take with these credentials, and it feels like an obvious best practice to keep them secret.
Thanks!
Can't you just put the keys and such in a .env file? This way nobody can see what keys you've got stored in there. You can then access your keys through process.env.YOUR_VAR
For Cognito you could store stuff like user pool id, app client id, identity pool id in a .env file.
NPM package for dotenv can be found here: NPM dotenv
Furthermore, what supersecret stuff are you currently storing that you're worried about? By "API tokens", do you mean the OpenId token which you get after authenticating to Cognito?
I can respond to the Cognito portion for this. Your AWS Secret Key and Access Key are not stored in the client. For your React.js app, you only need the Cognito User Pool Id and the App Client Id in your app. Those are the only keys that are exposed to the user.
I cover this in detail in a comprehensive tutorial here - http://serverless-stack.com/chapters/login-with-aws-cognito.html
I have set up a crossbar router server with several roles and each role has different register/call/subscribe/publish permissions.
Then I use the AutobahnJS client connect to the router. But I have no idea how to specify the client role(or AuthID by which the router determine the role of my client?) after searching the API Reference page
. Does anybody has any clue about this?
(P.S. The default 'anonymous' role is OK.)
You need to use an authentication mechanism when you want to specify a role other than anonymous. Authentication is described in the Crossbar.io documentation - see http://crossbar.io/docs/Authentication/. (Note: the documentation should be correct in what it describes, but a new, improved authentication scheme which is intended to replace WAMP-CRA, as well as client-TLS-cert based authentication are in trunk, but not yet documented).