I'm trying to authenticate my users (from my RN application) through the LDAP server (I've already found one to try authentication here, and it works!). I can create a custom token using Firebase every time I receive the credentials of the users (username and password) and save it in the Firebase real-time database.
The main problem is that I do not know how to connect my application with the LDAP server, I investigated and found that I have to install something like openLDAP or ldapjs but I do not understand how authentication has to be
My guess is:
User login in my RN application
The RN application sends credentials to Firebase
Firebase creates a custom token (uses the Firebase Functions to generate the custom token)
Firebase returns the custom token to the RN application
The RN application sends the token to the LDAP server (the server has predetermined users and passwords for testing)
The LDAP server validates the token, therefore, authentication
LDAP server returns attributes or "not found" to the RN application
RN App grant / deny access to the app
Any help or advice will be well received, thanks :)
Sorry for my bad english.
You're almost there, but instead of sending the Firebase custom token to the LDAP server, you authenticate the user with the LDAP server before minting the Firebase token. Both of these must be done in a trusted environment, such as a server you control or Cloud Functions, and you'll typically use a Firebase Admin SDK on that environment.
So:
User login in my RN application.
The RN application sends credentials to trusted environment.
Trusted environment verified credentials with the LDAP server.
Trusted environment creates a custom token using the Firebase Admin SDK. If needed this token can contain custom attributes from the LDAP server, in the form of Custom Claims.
Trusted environment returns the custom token to the RN application
RN App grant / deny access to the app
For more on this, see the Firebase documentation on custom auth. From there:
To achieve this, you must create a server endpoint that accepts sign-in credentials—such as a username and password—and, if the credentials are valid, returns a custom JWT. The custom JWT returned from your server can then be used by a client device to authenticate with Firebase (iOS, Android, web).
Related
I am currently working on a function app and would like to understand more on the built in authentication using Microsoft as the identity provider. I have created an app registration as per this guide but upon testing the authentication in a browser, I have been redirected to login.microsoftonline.com/common instead of login.microsoftonline.com/. Is that the expected behavior?
For your function app, in the Authentication blade, check what is being displayed for Issuer Url for the Microsoft Authentication provider. If you have configured to authenticate users from your organization's Azure AD, then that will be the tenant ID, and the url should be login.microsoftonline.com/<guid of tenant>. It depends on what you chose for your target audience, refer here.
I need to get authenticated using OAuth2 client credentials as the grant type. The app would need to call the OAuth2 server with only the client id and client secret, get authenticated and receive an access token back, then the app can use the access token to obtain the application's data. There is no regular user involved and the data belongs to the app. This is the same concept as your application connects to the database with a user name and user password belong to the application. The user uses the application without any knowledge of backend database accesses.
There are so many OAuth2 servers that support "code" grant type such as Google, Facebook, Github, but I have not found anyone that supports client credentials. Google asks me to set a service account, it is not the same as client credentials. Does anyone know an OAuth2 server that I use to test my client credential grant code? Thanks.
Keycloak has support for client credentials as authentication for the token endpoint.
https://www.keycloak.org/docs/latest/authorization_services/#_authentication_methods
I have an existing system and want to utilize Auth0(still considering).
Context:
I have my own login screen, which is quite dynamic(white labeled) per client. So I dont want to use Auth0 login screen.
I have my own user and tenant database, so dont want to use Auth0 user database for now.
So the idea is to validate the user credentials after login on my backend and create access token to return to client side.
I want that access token to be validated by Auth0.
Questions:
1) Probably most important question. Should go with Auth0 or just stick with native jwt's
2) Is there a way I can create a valid access token in my backend which can be validated by Auth0.
Stack:
I am using vue.js as my front-end SPA.
I am using .net core as my backend.
Probably most important question. Should go with Auth0 or just stick with native jwt's
That is determined by whether you want to enable the online identity provider's features like Single Sign-On . If not , just keep using the current one since you don't need the Auth0 user database .
Is there a way I can create a valid access token in my backend which can be validated by Auth0.
Since your scenario is collect username and password in front-end application , and pass to backend .net application to validate credential and create token . You can implement the Resource Owner Password Grant in Auth0 to create access token for accessing resource which protected by Auth0, but as document shows :
You should use this flow only if the following apply:
The application is absolutely trusted with the user's credentials. For Single-Page Apps and Native/Mobile Apps, we recommend using web flows instead.
Using a redirect-based flow is not possible. If this is not the case and redirects are possible in your application, you should use the Authorization Code Flow instead.
So that it's not recommended in your scenario . If you need the features like SSO and want to use Auth0 , it is recommended to directly use Auth0 in vue application to manage your users and roles :
https://auth0.com/docs/quickstart/spa/vuejs/01-login
After login with Auth0 , you can map the user to local database user for specific management if needed .
Another way is using Client Credential flow . For this scenario, typical authentication schemes like username + password or social logins don't make sense. Instead, M2M apps use the Client Credentials Flow , your backend app will authenticates and authorizes the app rather than a user. It's not suitable if you want to acquire access token for specific user to access protected resource .
I am developoing a flutter app and want to use Firebase auth service to enable my users to signup/login using:
email/pass
google
facebook
I have a lumen backend REST server with MySQL database.
Problem: Going through loads of firebase documentation I cannot understand the whole flow of how this should work.
I can successfully create users using the app and they appear in the firebase console, however, I don't know how to enable them to securely talk to my backend server.
I would expect Firebase to release an access and refresh tokens for me to use for my private communication between the app and backend, like AWS cognito does. Instead, it issues an "ID Token" that is JWT token and should be verified on backend. But what do I do once it is verified?
How do I link my users in my database to the authenticated user? What is the thing to store in the database to map to the authenticated user?
Do I have to generate custom tokens via the Admin SDK?
Or is the ID Token the thing that should be passed from client to backend on each request and then verified? But still, what do I put from this ID token to my database to link the authenticated user with their data?
Here's how I do it now. It works great.
Install Firebase admin sdk on your backend server, if you are using php, here is what I've followed and worked flawlessly: PHP Firebase Admin sdk
Aquire firebase idToken using firebase SDK in your client (app), I've used Firebase auth package for this.
Send idToken to your backend
Use Admin SDK to verify the idToken, if verification is successful it returns a Firebase user object. And you can perform various management actions on it (modify, delete, get different data etc.).
Get uid from the Firebase user object.
Store uid in your database.
Now each time this authenticated user makes a request to your backend server, you attach the idToken to the header of the request.
Each time you verify (see step 4) the idToken on your backend server and if the verification is successful you extract the uid to know which user to query in your database.
Any comments/improvements on this are welcome :)
The model for our product is like this:
Api backend (headless)
I already have oauth set up and ready to use with a resource owner credentials grant. Anyone who wants to use our api can do so using either an API key or their username/password. Of course they also need their client ID and secret.
SPA frontend that accesses the Api
I have built an SPA that will uses the api to provide a portal GUI for our clients. Given that this client-side app is owned and administrated by us (so it's a trusted app) how can I safely authenticate users using only username/password with oauth?
Originally it was using a JWT auth system that only required username/pass but now that we've implemented oauth I'd like to consolidate. It's unreasonable to make every user need to also have their client id and secret on hand to login, but I want users to have full access to the api from the GUI.
I've looking at using CSRF tokens but how would that work with my app when nothing is generated server-side?
I'm not sure how to proceed.
EDIT: very similar to the problem here.
I have decided to use the solution described here.
And here is a snippet of my implementation
The TL;DR version is
Create a proxy between the app and the api
Store the client ID and secret in the proxy
App logs in using password grant type -- proxy intercepts login request and inserts client id and secret
On login response proxy returns access token as an encrypted cookie
Client stores cookie and sends with api requests (to proxy)
Proxy decrypts cookie and inserts access token into Authorization header before forwarding to api endpoint
For me this has several advantages over implementing something custom on the api itself:
No need for custom grant on oauth server
ID/secret is hidden from app securely and can still use password grant
oauth server can identify client (no need for separate client ids for each user)
You should not use the resource owner credential grant from a JavaScript application. The fact that you own and administer the application does not make it a trusted application.
A trusted client is an application that can keep a secret. SPAs or any JavaScript app cannot keep a secret.
You should use the implicit grant for non-trusted clients.