SPA and BFF on different sub-domains, BFFs for mobile apps about openiddict-core HOT 6 CLOSED

I don't know much about it, but it seem to be a thing, for API optimization and auth.
Brave Mobile World: OAuth in Native Apps

I don't see anywhere in that post where they recommend using a BFF for a mobile application: this post isn't about the BFF pattern at all - it's not even mentioned - it simply clarifies the fact mobile applications should be declared as public clients (which is standard practice and fully supported by OpenIddict too)

and setting the domain value of the cookie on the BFF didn't work.

Unfortunately, you decided to ignore my recommendation to use a BFF per SPA and serve that SPA via the BFF to avoid any origin mismatch/cookie sharing issues (which is the standard approach) and opted for a more complex setup.

As I mentioned in the other thread, I'm unable to repro your issue locally and you didn't provide a repro yourself, so I can't help you more with that, unfortunately.

from openiddict-core.

I managed to make things work by redirecting all traffic through the BFF then proxy the API to API and the UI to UI, now the problem here is a big a mount of work is needed to setup the dev environment for testing.(domain, host on iis, publish to update)

On the other hand I found about the Asp.net core React templates which could work as a middle ground, and for the UI + BFF I think it will be fine, however I also need to customize the UI of the Auth\SSO server, and checking the other recent thread about using SPA for UI, I found that you have APIs to use instead of MVC for authorization in the Mimban sample and you mention the .NET 8.0 identity APIs, which I also tested.

Now does these APIs work fine with OpenIddict? for example, I login and use cookies, so now I have a cookie, can I get user info using that cookie? I am getting a 401 when I use UserInfo controller from Dantooine.

from openiddict-core.

I made a minimal API and it worked

app.MapGet("/account/userInfo", async Task<IResult> (HttpContext context, ClaimsPrincipal user, UserManager<ApplicationUser> userManager) =>
{
    var _user = await userManager.GetUserAsync(user);
    if (_user == null)
    {
        return TypedResults.Challenge(
            authenticationSchemes: new List<string> { OpenIddictServerAspNetCoreDefaults.AuthenticationScheme },
            properties: new AuthenticationProperties(new Dictionary<string, string?>
            {
                [OpenIddictServerAspNetCoreConstants.Properties.Error] = Errors.InvalidToken,
                [OpenIddictServerAspNetCoreConstants.Properties.ErrorDescription] =
                    "The specified access token is bound to an account that no longer exists."
            }));
    }

    var claims = new Dictionary<string, object>(StringComparer.Ordinal)
    {
        // Note: the "sub" claim is a mandatory claim and must be included in the JSON response.
        [Claims.Subject] = await userManager.GetUserIdAsync(_user)
    };

    if (user.HasScope(Scopes.Email))
    {
        claims[Claims.Email] = await userManager.GetEmailAsync(_user) ?? "";
        claims[Claims.EmailVerified] = await userManager.IsEmailConfirmedAsync(_user);
    }

    if (user.HasScope(Scopes.Phone))
    {
        claims[Claims.PhoneNumber] = await userManager.GetPhoneNumberAsync(_user) ?? "";
        claims[Claims.PhoneNumberVerified] = await userManager.IsPhoneNumberConfirmedAsync(_user);
    }

    if (user.HasScope(Scopes.Roles))
    {
        claims[Claims.Role] = await userManager.GetRolesAsync(_user);
    }

    // Note: the complete list of standard claims supported by the OpenID Connect specification
    // can be found here: http://openid.net/specs/openid-connect-core-1_0.html#StandardClaims

    return TypedResults.Ok(claims);
}).RequireAuthorization();

However it seem using the MapIdentityApi register doesn't add scopes! I am not sure where I got this, but I am using both:

builder.Services.Configure<IdentityOptions>(options =>
{
    // Configure Identity to use the same JWT claims as OpenIddict instead
    // of the legacy WS-Federation claims it uses by default (ClaimTypes),
    // which saves you from doing the mapping in your authorization controller.
    options.ClaimsIdentity.UserNameClaimType = Claims.Name;
    options.ClaimsIdentity.UserIdClaimType = Claims.Subject;
    options.ClaimsIdentity.RoleClaimType = Claims.Role;
    options.ClaimsIdentity.EmailClaimType = Claims.Email;

    // Note: to require account confirmation before login,
    // register an email sender service (IEmailSender) and
    // set options.SignIn.RequireConfirmedAccount to true.
    //
    // For more information, visit https://aka.ms/aspaccountconf.
    options.SignIn.RequireConfirmedAccount = false;
});

and

        options.RegisterScopes(Scopes.Email, Scopes.Profile, Scopes.Roles, "api", "workflow");

from openiddict-core.

I managed to make things work by redirecting all traffic through the BFF then proxy the API to API and the UI to UI

Nice 👍🏻

now the problem here is a big a mount of work is needed to setup the dev environment for testing.(domain, host on iis, publish to update)

Haha, yeah, I can imagine 😄

Now does these APIs work fine with OpenIddict? for example, I login and use cookies, so now I have a cookie, can I get user info using that cookie? I am getting a 401 when I use UserInfo controller from Dantooine.

No, you can't: the userinfo controller (that could also be a minimal API handler) is exclusively used for OIDC, which requires sending a valid access token.

However it seem using the MapIdentityApi register doesn't add scopes! I am not sure where I got this, but I am using both:

That's expected, scopes are an OAuth 2.0/OpenID Connect concept: if you implement a custom, non-OIDC userinfo API, scopes won't be there at all.

from openiddict-core.

That's expected, scopes are an OAuth 2.0/OpenID Connect concept: if you implement a custom, non-OIDC userinfo API, scopes won't be there at all.

how to work around this? do an old fashioned Users API?

from openiddict-core.

how to work around this? do an old fashioned Users API?

If you absolutely need a "userinfo" API that directly accepts cookies, yes. Otherwise, you could use your BFF proxy to handle the "cookie -> token conversion" and use a standard OIDC userinfo endpoint: in this case, you'll be able to use scopes.

from openiddict-core.