I am currently using Firebase Authentication in my app using the built-in OIDC providers (Google, Facebook etc.). Is it possible to use Okta as an additional OIDC provider with minimal modifications to my app, meaning Okta should behave just like any other built-in provider? Firebase Auth apis, such as firebase.auth().currentUser and firebase.auth().onAuthStateChanged() should still work.
The doc page for Custom Authentication talks about getting a custom token from an auth server, but does not clarify if that's an OAuth access token. Is there an example of Okta integration or a generic OIDC integration that works seamlessly with Firebase auth?
There's no built-in Okta provider for Firebase Authentication, but if you have an existing authentication flow for it, it's fairly easy to integrate it into Firebase as a custom provider.
It's a 6 step process:
You gather the user credentials on the client.
You pass those credentials to a trusted environment, either a server you control, or Cloud Functions.
On the server you verify that the credentials are correct according to Okta, typically by calling a server-side API they provide with a key you provide.
You then use the results of that call to mint a new ID token for the user. This is a JWT, not an OAuth access token.
You pass back that ID token from the server to the client.
The client then calls firebase.auth().signInWithCustomToken(token) with the ID token, to sign in to Firebase Authentication.
Related
I have a django restframework backend and a react frontend that uses google social auth to authenticate human users. The flow is a relatively simple JWT flow.
The user goes to my website
The user logs in with their google account
the google window sends a credential to my backend
the credential is verified on the backend
I send back an access token that allows the user to use my app which makes rest calls to my backend
I would like to generate a similar access token to pass to the backend so that I can access my api from lambda functions.
Is it possible to use the client_id and client_secret from my google console credentials to generate the same type of token to send to my backend? I've also looked into google service accounts, but this seems to be used specifically for accessing google services, not a generic API that is simply protected via google authentication.
If none of the above options work? How would you recommend I authenticate machine users via google auth?
Alright, so I'm having a hard time understanding a proper flow here for my setup.
Goal
I want to have a proper SSO flow for my SPA app that can authenticate users into an API.
Context
I have a React application that is intended to use an Okta porta that offers both SAML (preferred) and OIDC for SSO flows. I've wrapped my static sources in a web server that serves them, and that server has a middleware that checks for cookies, and if one doesn't exist, I redirect to the IDP (Okta) for login. This all works fine for now.
Currently, my API sits on that same server, which I intend on moving to a separate server to scale independently of the website. My API must also allow other machine clients (services) to call into it, so I implemented a service account flow that uses client ID and secret as the authentication measure.
In general, my intended flow looks like this:
User navigates to my website (unauthorized) -> Web Server -> Redirect to IDP -> Assertion Callback flow -> Generate JWT session cookie -> Web Application makes API call -> API Server auth middleware validates cookie / bearer token.
The problem.
The details of how the JWT access token is generated is where I'm stuck. Currently, my webserver receives the SAML assertion and generates a JWT, which is not the same JWT claims logic as the service accounts (bleh). I'm thinking of implementing an Auth service instead to centralize the token generation flows.
For the Auth Service, I've looked into OAuth2.0 and it seems like just the right approach for what I need. With that said, I can't find much information on patterns to follow for SAML assertion -> OAuth2.0. I saw an IETF draft for saml2-bearer grant-type, but it seems dead in the water. I'm also unsure about the general consensus on custom implemented OAuth2.0 grant types.
What does a proper flow look like? I have a couple of scenarios in mind:
SAML Service Provider within the same service as the Auth
Service. On lack of SSO session, my application redirects to my Auth service, which then redirects to my IDP. The IDP calls my SP (the auth server) with the assertion, the auth service generates a token, then my auth service redirects back to the webserver with a cookie placed in the response headers.
SAML SP as the webserver Since the webserver is the only system that needs to use the SSO, I could just keep the SAML flow within that process. Once my webserver receives the SAML assertion callback, my server makes a call to an endpoint service with the assertion claims, and then my auth service returns the access token in a JSON response.
Something else, like OAuth2.0 authorization code flow with PKCE for the web application. Or OIDC instead of SAML for SSO.
OIDC sounds like the right choice for you as APIs are involved. OAuth is designed to secure APIs' compared to SAML which is built for enterprise SSO.
You can integrate your SPA with Okta using OIDC. Okta provides SDK's for varies platforms to make it easier for you to do so. You can find SDKs' here:
https://developer.okta.com/code/angular/okta_angular_auth_js/
Once you get an ID token and Access token from Okta after OIDC flow, you can use the access token to access external API's. Your API resource server or the API gateway can validate the access token. Again Okta provides SDK's to verify access tokens: https://developer.okta.com/code/dotnet/jwt-validation/
I have some questions because I don't understand well how implement authentication flow.
Reading some docs I found image below
Now, I understand the access token and refresh token, but I don't think I understand how to implement it.
I have a project where frontend is angular and backend is node.js koa with microservices architecture and gateways in front of them.
I can use auth0 like oauth2 authorization server with users stored inside?
How? In auth0 docs there are tons of instructions and I cannot understand which is right for me.
I have to intercept login, logout and sign up by gateway and redirect to auth0 or I have to do this inside my user microservice?
Does a user table make sense in my project(s) where there are also personal info table and company table?
Is in this way the authorization server sso for all my company projects?
Can I add external company's SSO?
Can I add Google sign in?
You can follow Auth0 Angular Quickstarts to implement your scenario. It exactly shows step by step implementation. https://auth0.com/docs/quickstart/spa/angular2/01-login
From architecture level, you are doing following:
Frontend application (angular) uses auth0-spa-js to implement Authorization Code flow + PKCE to implement login flow. It simply performs user authentication and obtain a token which request API scope as well. To request API permission, add the audience parameter when initiating the login flow.
Once you obtain the token, access token can be used to call your backend API.
In the backend server , you should implement API authorization (It validates the access token and check token have necessary scopes/ permission). https://auth0.com/docs/quickstart/backend/nodejs/01-authorization
Above API authoriazatio quickstart uses express middleware. This blog post explains how to do the same in koa . https://auth0.com/blog/building-and-securing-a-koa-and-angular2-app-with-jwt/
you have a very broad architectural implementation question for your specific organization case.
I would recommend you follow the below user management model which takes care of
Simple API for Authentication, Registration and User Management using NodeJS + Koa + Passport combination.
You can deploy the API to Heroku and test the API using Postman.
You can use the NodeJS Global Error Handler Middleware and you do not have to implement any reduntant local error handler.
As a best practice, use the node JWT middleware that checks the JWT token received in the http request from the client is valid before allowing access to the API, if the token is invalid a "401 Unauthorized" response is sent to the client. This JWT API authorization can be done at your gateway level itself before your microservices.
Finally the Koa + Passport user service contains the core business logic for user authentication and uses Koa-Redis for session management in the node api, it encapsulates all interaction with the mongoose user model and exposes a simple set of methods which are used by the users controller.
Moroever Koa + Passport supports Single sign-on with OpenID and OAuth which answers your other question related to SSO.
Here too you can find that KOA is best suited for microservices as you have already chosen the same. Overlaying authentication + user management using the same infrastructure will prove to be very versatile and extensible.
https://mherman.org/blog/user-authentication-with-passport-and-koa/
In order to connect to an external SSO provider, you could use the nodejs oauth2 client api as follows which allows you to connect your node backend to connect to an external SSO server.
https://www.npmjs.com/package/client-oauth2
For SSO using Google/Gmail, it is best to use SAML based SSO provided by google.
Security Assertion Markup Language (SAML) is an XML-based framework for authentication and authorization between two entities: a Service Provider and an Identity Provider. The Service Provider agrees to trust the Identity Provider to authenticate users. In return, the Identity provider generates an authentication assertion, which indicates that a user has been authenticated.
SAML is a standard single sign-on (SSO) format. Authentication information is exchanged through digitally signed XML documents. It's a complex single sign-on (SSO) implementation that enables seamless authentication, mostly between businesses and enterprises.
below link provides details of how to setup a SAML/SSO service into google from your application.
https://support.google.com/a/answer/6087519?hl=en
I would like to design a micro-services architecture with IBM connect where the outside clients need to pass a Bearer access token in an Authorization header (OAuth 2) and the gateway will pass a stored JWT (generated and stored during authorize call) with the authorized user's claims to the internal APIs.
Is there such a built-in configuration?
(For reference, WSO2 provides this exact behavior: https://docs.wso2.com/display/AM210/Passing+Enduser+Attributes+to+the+Backend+Using+JWT)
There is not such built in feature in IBM API Connect.
A possible implementation for the scenario that you mention, in IBM API Connect, could be:
An OAuth Provider API that contains the authorization and token endpoints of an OAuth flow (IBM API Connect has a built-in OAuth server) Implement an OAuth API Provider
The API that acts as a proxy of the backend microservice, secured by the OAuth provider API created before (so that way, access tokens are required to send requests to this API). In this API, implement a jwt-generate policy (which is a built-in policy in IBM API Connect) to generate JWT tokens. jwt-generate built-in policy
In this implementation you can add custom information to the access tokens generated by the OAuth provider API (such as the logged in user in the application, device id....), and use those values as claims when generating the JWT (oauth.resource-owner, client-id of the consumer application sending the requests....)
I need to implement an authentication mechanism with JWT tokens for an mvc web application and a mobile application as well. Users will be able to register to our database and authenticate by using credentials (from signup) or use facebook single sign on. Both applications will use web API for data exchange with JWT token. I am thinking of using Identity Server 3 for that using Resource Owner Flow and i have some questions on that:
1) User will login from mobile application and will get a jwt token. Mobile application will verify it's validity and will refresh when needed. In order for mobile application to have user always logged in should i store refresh_token on device??? Is it secure?
2) I cannot understand how am i going to handle facebook authentication and get jwt token from identity server. Should i first get users email from facebook profile data and then what???
Thank you
1- You can store refresh token in database( identity server provide a token stor)
also you can use third party library to store tokens in device securely.
2-To use the 3rd party logins you need to do the redirect style to the IdSvr login page. Using resource owner password flow means you miss out on all the features in the token service like SSO, 2fa and federated authentication.