Best practices in saving user data when using identity provider like AWS Cognito

authenticationawsidentityonline-identity

So in my mind, the usual users table that we are used to having, is going to split in two:

whatever data is within the Identity Provider
the domain specific data (user.facialHairStyle) is going to still stay in the user table. One difference is that it will be missing the regular properties covered by the Identity Provider: name, sex, mail…

Gotta be honest. I far from like this. First dumb example that comes to mind:
User registers, the app handles that by creating a user entry with domain-specific data with id of the identity pool entry. What if the user entry creation fails? Do I need to invent rollback procedures? Do I unregister the user?

Best Answer

I’ve done this before, where data in a third party service needs to be in sync with data stored in my in-house SQL database.

The best way that I could come up with was to start a local database transaction, provisionally insert the local data, reach out to the third-party service and do my data creation / insert there, verify the third-party service call completed successfully and obtain any third-party ID as necessary, then within the same local database transaction update the requisite data, then and only then commit the database transaction.

If the third party service fails, you can rollback the transaction and you have no dangling local data. If the commit fails, you can rollback the third-party service creation manually.

The only downside is that if the third-party service is slow, you have the potential for long-running transactions which can be problematic and lead to deadlocks in specific cases.

But on the whole this works well enough when I’ve done it.

Related Solutions

How to keep user logged in when using OpenID Connect & Cookies in dotnet core

I did this myself recently and it's a bit of a pain, largely due to the limitations on the extension method setup methods which restrict your control over the component, forcing you to use CookieAuth when you don't really want to.

What I setup was Cookie, JWT and OpenIdConnect authentication. in the cookie auth we forward events to the JWT or OpenId auth

.AddCookie(options =>
{
    options.ForwardAuthenticate = JwtBearerDefaults.AuthenticationScheme;
    options.ForwardChallenge = OpenIdConnectDefaults.AuthenticationScheme;
    options.Events = new CookieAuthenticationEvents()
    {
        OnRedirectToAccessDenied = async ctx =>
        {
            ctx.Response.StatusCode = 401;
        },
    };

})

In the JWT auth we check our own cookie:

options.Events = new JwtBearerEvents()
{
    OnMessageReceived = async ctx =>
    {
        //get the token from the cookie rather than the header
        var token = ctx.HttpContext.Request.Cookies["access_token"];
        ctx.Token = token;
    },
};

In the OpenId auth we set the cookie

ctx.Response.Cookies.Append("access_token", tokenResponse.AccessToken);

Best Answer

Related Solutions

How to keep user logged in when using OpenID Connect & Cookies in dotnet core

Related Topic