Let's say I have two applications, appA and appB. appA has a simple database authentication approach and appB uses ForgeRock's OpenAM. I want a user in appA to be able to SSO into appB. Because the username/password in appA is different then the creds in OpenDj, I'm wanting to add a column to my user table in appA called external_user_id. I would then use this to generate a token to hand over to appB. I'm curious if there is a way in OpenAm to generate tokens for a user using only their username and not their password. If there was the idea of a serviceAdmin account that lets appA generate tokens based on just a username, that would be awesome, but I'm doubting that something like this exists. Is there something like this in OpenAM that I'm missing?
The best way to tackle this kind of a situation is to write a custom authentication module that would receive a session ID or a "secret" from appA, then validate it and issue a new session on the OpenAM domain, and thus giving access to appB.
Related
I would like to support this scenario in my app:
User visits standard application URL https://app.example.com/
User logs in and receives a JWT token from server, to maintain a login session
App determines that user's account has a custom domain assigned
App redirects to custom domain https://custom.customer.com/
User remains logged in without having to re-login
Step 5 is the only difficulty. Does anyone have any advice on how this can be achieved securely? I've seen suggestions to pass the JWT as a parameter in the redirect, but this seems exceedingly insecure to me.
I'm thinking of one option, that may be at least more secure... A one-use "transfer" token could be created by the server. This would be passed in the redirect URL, and the (same) app at the new URL could pass this to the server to get the JWT. Thoughts on this?
Thanks.
You should not pass the actual authentication token (jwt) in the url for multiple reasons. Sensitive data should never appear in urls.
Passing a one-time token to be exchanged for the authentication token is somewhat more secure, but you either can make it purely stateless or one-time, but not both, because you will have to remember used tokens. That's fine, just something to consider. Also if you can pass it in the request body or header, you should (eg. a post request would have it in the body instead of the url).
However, if you are doing this, you are reinventing single sign-on. What you need is already available in multiple different forms, most notably OIDC and SAML. In a more best-practice-like architecture, you would have a login endpoint that would act as the authentication provider (say an OIDC provider). That would issue auth tokens that consumers (relying parties in OIDC terms, these are basically your apps) could consume either directly or make their own sessions based on the tokens received from the identity provider.
In case of the authorization code flow, it would look something like
user visits app1, but is not logged in (does not have valid tokens or a session)
user gets redirected to the login server, where he logs in and is redirected back to the app1 with an auth code
app1 in the background could exchange the code for tokens that you could use on your backend to impersonate the user, so every backend component can make sure who the user was, and also in this step app1 can create a plain old session for the user if it wants
in subsequent requests, the user would already have the session (or an id token)
when the user visits app2, depending on what exact flow you choose, the client would either have an id token already that it could send to app2, or would be redirected to the login server, but there the user would be logged in already, so it would all be transparent from a user's perspective and app2 would just work.
A major benefit of the above is it's a standard approach, there are well-tested flows and ready-made components that you can use and with which you can achieve a reasonable assurance that they are secure. Another benefit is that all components are replacable, you can switch to another identity provider relatively easily (you can choose from many, including open source options, or very cheap hosted ones), and relying parties (apps) will also be easy and standard to make.
I have a Node.js application that offers several different routes in front of MongoDB. I need to make sure that only authenticated requests can access these routes.
Ideally, I want to set it up so that a username and password comes in to the API, and in a response we give them back a token. I don't mind managing the tokens inside MongoDB myself, but I need to make sure that the token we give back can make authenticated requests. I don't want to force the user to send their credentials each time, just the token.
I've read for a few days about passport, and there's currently 307 strategies. Which strategy am I describing here?
Which strategy am I describing here?
You are describing a Local Strategy.
As per their description:
This module lets you authenticate using a username and password in your Node.js applications.
I don't want to force the user to send their credentials each time, just the token.
Passport auth strategies just provide various ways to authenticate (or in simple terms login) the user, not how to persist that login. Login persistence is usually done with user sessions.
One way you can solve this is to combine the local strategy with the express session middleware. Combination of the two allows for a fairly simple auth system that requires the user to login once and then persists the session.
In a typical web application, the credentials used to authenticate a user will only be transmitted during the login request. If authentication succeeds, a session will be established and maintained via a cookie set in the user's browser.
Each subsequent request will not contain credentials, but rather the unique cookie that identifies the session. In order to support login sessions, Passport will serialize and deserialize user instances to and from the session.
PassportJS docs give an example how to achieve this.
For this you should prefer generating JWT tokens for a the login and then using the token to always authenticate user actions.
Following steps are need to implement this style of token login system
generate token on login
verify when token supplied and use the decoded data to identify user
use should proper middleware in order to protect your api.
Here is a link you could follow:
https://scotch.io/tutorials/authenticate-a-node-js-api-with-json-web-tokens
I'm trying to build an authentication service with express.js, but I didn't catch the idea of authentication modules yet.
What's difference between passport and oauth middleware? Are they dependent of each other? Is useless to have the BearerStrategy without an oauth server to generate tokens to the BearerStrategy validate? Am I on the right way?
I've read about oAuth2 and Its authentication flow, but I'm still lost with this uncoupled code.
I'm trying to build the Resourse Owner Password authentication with refresh token for my AngularJS frontend communicating with the backend API, and I'm facing with many combinations of password.js strategies (Basic, Bearer, ClientPassword) with oauth2orize on the other side.
So, I'd like to know a very simple explanation of how authentication works on NodeJS. At really I know that Express is not inventing a new way of how authentication works, but the modules are too unobtrusive that I need to understand the base of how It works to achieve them working together.
Passport is authentication middleware.
OAuth is authorization middleware.
To understand the difference:
Authentication is the process of ascertaining that somebody really is who he claims to be.
Authorization refers to rules that determine who is allowed to do what. E.g. Bob may be authorized to create and delete databases, while Bobbette is only authorized to read.
In other words. Authentication is your username + password. Authorization is what you're allowed to do.
Passport will allow you to authenticate the user before allowing access to your API. It does not (directly, it's possible) allow to check if a user is allowed to perform an action after authentication.
Check this Wikipedia for more on Authentication vs Authorization.
What OAuth does that Passport doesn't, is that it allows users to grant a service access to their personal information. It also allows users to allow or disallow certain privilages (scopes in OAuth).
Do note that there are a lot of OAuth flavors. The most common is the version with authorization grant types seen when authorizing with Facebook or Google. But there are many others including the Resource Owner Password strategy you mentioned.
I'm learning Node, doing authentication stuff at the moment with passport.
Say my server has 2 pages, a public home page with various login options, then a super-secret page(and perhaps more) that is only accessible after authenticating.
If I'm only going to be using 3rd party strategies, is there any reason to have a database?
I know that you'd obviously need one for local user's id and pass, but if the server exclusively relies on 3rd party authentication, would session persistence be enough things to work? Or are there still various things that you would need to save for some reason (apart from logging) ?
Could you do without a database, sure... but in this case what is the point in authenticating at all? All you would be proving is that the user has a Google account which anyone can set up for free in a matter of minutes.
If your content is super secret then chances are you want to have a database of users (email addresses and the like) that have permission to see the content. By authenticating through OAuth you will be given an access token that will allow you to fetch the authenticated users email address. This can then be looked up against your user table to see if the user is registered and if your app enforces it, check whether the user has access to the page requested.
OAuth is proving that this person is the owner of the Google/Facebook/Twitter/Github Account. You can use this knowledge to sign someone in against a database of "local accounts" based on email used at sign up, assuming you validate the email on sign up locally.
I want to built a SSO Service with nodejs.
I have been looking in oauth methods and passport examples, but did not come to a conclusion.
I want to have an Identity Server like https://id.mycompany.com, where the user can create and edit his profile. He also should see what services he can use from my company.
There will be another resource like https://app1.mycompany.com. If the user enters this page he will be redirected to id.mycompany.com to authenticate, and if so, he will be redirected back to app1 with access granted.
Is this an oauth2 mechanism? Because I don't want the user to decide if app1 gets access. I want to decide which user have access to resources of app1.
So I need kind of oauth, but without the client_id part in the redirect url, because I own all Servers.
Hope you can help me, or what I need to search for.