Topics created by fred.fred

@fred-fred If no application id is provided when using the Login API, then there is no application in the reporting, since FusionAuth doesn't know the application. I'm not sure if you are using the Login API, but people can authenticate without an application id.

Here's more documentation about this issue: https://fusionauth.io/docs/v1/tech/core-concepts/authentication-authorization

@johnathon

Also, if you are using Graal, using let and const will not be supported until version 1.37.0.

https://github.com/FusionAuth/fusionauth-issues/issues/179

@fred-fred said in Where to put SAML metadata if FA is acting as IDP?:

But it looks like this is the only place to enter SP metadata info, correct?

I'm not sure I understand what you mean.

@fred-fred said in Custom theme deployment between environments:

It looks like we can transport with the API using Theme Update Endpoints and sharing environment API keys so one environment can see the next environment to copy the themes over.

Yes, that's what I'd recommend. You could have different API keys for each environment and have the script that promotes the theme pull the API key from a secrets store. Make sure you limit the API key to the themes endpoint.

You also might be interested in this post: https://fusionauth.io/community/forum/topic/1306/parameterizing-themes which indicates how you can have the same theme files point to different resources in staging/prod/dev/etc.

Ok this is how I fixed the post_logout_redirect_uri issue.

In my logoff method, I did this to remove the local cookies

c99db979-5e36-4e07-8cbd-8ce25bd73775-image.png

Then because I could not use the Owin..OIDC..PostLogoutRedirectUri in the OpenIdConnectAuthenticationOptions to pass the client_id

At the end of the logoff method, I just did this:

39f0427a-f30a-4e54-b719-1c6689476674-image.png

This removed the FusionAuth session, does the log out, and redirects to my home page

Thanks to all who tried to help out

@fred-fred

I am not sure if this is a bug, but rather may be a security limit placed by the OAuth protocol that you are implementing through FusionAuth. I will have to check to see if this pattern --- file:///... qualifies as an absolute URI.

In FusionAuth, the only valid redirects are outlined below.

An array of URLs that are the authorized redirect URLs for FusionAuth OAuth. Examples of valid redirect URIs: - https://example.com/redirect - com.myApp://redirect - com.myApp:/redirect AVAILABLE SINCE 1.7.0 You may now use URLs that do not begin with http to support native application redirect. Prior to this version the value will be validated to begin with http. AVAILABLE SINCE 1.12.0 You may now use URLs for application redirects that use a single slash to denote there is no naming authority for the scheme. Prior to this version a URL such as com.myApp:/redirect would fail validation as in invalid URL.

https://datatracker.ietf.org/doc/html/rfc6749#section-3.1.2
From the OAuth spec

3.1.2. Redirection Endpoint

After completing its interaction with the resource owner, the
authorization server directs the resource owner's user-agent back to
the client. The authorization server redirects the user-agent to the
client's redirection endpoint previously established with the
authorization server during the client registration process or when
making the authorization request.

The redirection endpoint URI MUST be an absolute URI as defined by
[RFC3986] Section 4.3. The endpoint URI MAY include an
"application/x-www-form-urlencoded" formatted (per Appendix B) query
component ([RFC3986] Section 3.4), which MUST be retained when adding
additional query parameters. The endpoint URI MUST NOT include a
fragment component.

@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.