Is there an example of how to authorize a user to an app and allow them to access after using the login API?

fred.fred

Re: Can I add new functionality to the login page?

In the above post, we want to implement @dan example initially:
don't use our hosted login pages, instead build your own login pages (and all the other stuff like reset password, etc) using the Login API. You get total control of the login experience, at the cost of more custom code.

We already have a SSO that forms auth's our users with our own DB.

We have already loaded our users into FusionAuth (FA) as well.

What we want to do is have our users login to our SSO, then we will call FA's login API.

Then when they hit the portal page of our SSO, we want them to be able to click a tile which is linked to https://MY_FA_SITE/oauth2/authorize?client_id=SOME_CLIENT_ID&response_type=code&redirect_uri=https%3A%2F%2FMY_OIDC_SITE.COM%2Fcallback (I think this is the correct url?)

Which ends up sending them into https://MY_OIDC_SITE.COM/ without having to login to FA again.

Can someone point us towards resources that will allow us to do this in NET Core, NET framework, or pseudocode?

Or give us a hint as to what type of login flow this is?

Thanks.

joshua

Hi @fred-fred,

The link you have provided is referencing the OIDC protocol which is outlined here in FusionAuth.

I am a bit confused by your use case. What is the primary purpose of FusionAuth in this instance? Are you using an OIDC compliant SSO? If you could elaborate a bit on your current implementation and the steps you would like to have occur, I may be able to offer a few more pointers.

Other reference materials to get you going

You may want to reference our external identity providers and reconcile lambda functionality

Our Single Sign On(SSO) guides may also be of use to you as well.

https://fusionauth.io/docs/v1/tech/guides/single-sign-on/

We do have a few examples using Netcore which you can review:

https://fusionauth.io/docs/v1/tech/example-apps/netcore/

Thanks!
-Josh

fred.fred

@joshua thanks for replying

Here are some answers to your questions:

I am a bit confused by your use case. What is the primary purpose of FusionAuth in this instance?

We want to use FusionAuth (FA) to authorize users to FA protected OIDC apps after we login to our current SSO, which uses forms auth.

We thought calling the FA /API/login API was the same thing? And that after we logged in there, we were authorized for FA protected apps the logged in user was registered to.

But it looks like FA /API/login API is just authentication, so I guess we need the authorization part that allows users to now get into FA OIDC protected apps, without having to login again.

Are you using an OIDC compliant SSO?

No, we have a custom SSO, based on forms auth, with some old Open Id 2.0 and custom "SSO" links behind it on a portal page. Once logged in, you click over to these sites from the portal page. We want to move from Open Id 2.0 to OIDC and SAML, where appropriate.

If you could elaborate a bit on your current implementation and the steps you would like to have occur, I may be able to offer a few more pointers.

Initial phase (6 months), we want to do something like this:

6 months will allow us to clean up our user base, finish evaluating FA custom registration forms, and get our FA custom themes done.

In the meantime, we still want our users to be able to use our custom SSO to get to their sites daily, with no drastic changes in the current, custom SSO site.

After 6 months, we want our login process to look like this:

We will basically strip the old SSO site of any SSO capability and give that to FA, which will turn it into a regular OIDC protected page, which requires login to styled FA login page to get authenticated and authorized to allowed apps.

Does this make make sense?

We are basically stuck on the SSO session part. We can login (authenticate) with FA, but now we need to authorize our users into to their registered OIDC sites without them having to login to FA again.

Thanks for any help.

joshua

@fred-fred,

I will try to offer a few pointers, but as always, the juice is in the details. If you find yourself wanting more guidance, we do offer support plans to assist with implementation (not an upsell, just an option if needed per business requirements )

You could add Your Custom SSO as OpenID Connect Identity Provider. My thinking is that you could have FusionAuth issue an access token by visiting a login page and have your custom SSO accept that token, verify it, and then offer access to all the applications behind its "gate". In the picture from the documentation, replace pied piper with custom sso login button. Disclaimer: I may have to think more on this one to see if it best applies.

If you want to follow OIDC you will want to review the endpoints found below:
https://fusionauth.io/docs/v1/tech/oauth/endpoints/

I will see if @dan, my colleague, has any other directional pointers to add or if I anything else pops to mind.

Thanks,
Josh

Other Resources

Many people use connectors when doing a staged migration of a system (documentation here) as you are. That would be a workflow to consider and educate yourself on. Specifically, there is a section in the documentation on Authentication that might be helpful to you.

Finally, you could peruse our migration guide, to review for tips as you move forward. https://fusionauth.io/docs/v1/tech/guides/migration/

dan

Just wanted to chime in that it sounds like, based on my quick read, you want to be able to replicate FusionAuth's SSO capability (and share it between your custom SSO implementation). The SSO functionality details are not something we expose, it's built into the hosted login pages. From https://fusionauth.io/docs/v1/tech/core-concepts/integration-points/#hosted-login-pages

Additionally, when you use the hosted login pages, FusionAuth provides transparent single sign on (SSO) between applications as well as support for localization of the user interface.

We don't really offer architectural advice with community support.

That said, would love to hear what you come up with, or maybe someone else with a similar problem can share how they solved it.

fred.fred

@dan said in Is there an example of how to authorize a user to an app and allow them to access after using the login API?:

The SSO functionality details are not something we expose, it's built into the hosted login pages.

@dan yeah that is what we figured, so we are working on option 2 now, which is to make a host portal site protected by FA login, which will issue the cookies and sessions, to allow access into protected, registered content, after successful login.

May I ask, why do you have /API/Login if all it really does is authenticate but not authenticate and authorize like the Login pages?

Thanks too @joshua

dan

@fred-fred said in Is there an example of how to authorize a user to an app and allow them to access after using the login API?:

May I ask, why do you have /API/Login if all it really does is authenticate but not authenticate and authorize like the Login pages?

I'm not sure I totally understand the premise of the question. I hear your frustration, however.

The Login API provides a JWT, which can be used for authorization. It seems like you are looking for configurable SSO which is, as I understand it, a different thing.

Our SSO implementation (like almost every other SSO implementation for web browsers) depends on cookies, which are not really something you can set with a backend API in a effective way (because the cookies have to be set by the component responding the browser, which the Login API will not be.) If there's an SSO implementation that is available via an API, please share that as we're always looking to improve.

When you use the Login API, you have complete custom control over every aspect of the UX. But with great power comes great responsibility , and part of that responsibility is re-implementing SSO.