When using Implicit Flow with a SPA, where do we actually create the account in our Database?

I'm trying to understand how OAuth2.0 Implicit Flow (with OIDC) works with a pretty simple SPA/Mobile client (aka Client) and my REST Api (aka Resource Server) and creating new accounts.

I more or less understand how the Client can request a token from an Auth Service (Auth0/Stormpath/IdentityServer/etc). It then uses this token to access restricted API endpoints.

But all the examples I keep reading are that the 'accounts' are created on these Auth Services (which is required and I understand) but nothing is created on my service (my Resource Server).

I need to create an account in my DB because I have user data/settings I wish to store (eg. orders they make, etc). Of course, I do NOT want to store any security information .. because that's why I'm using an external Auth Service.

So, would anyone explain how they use implicit flow and .. when a token (or more specifically, when OpenID Connect is used to get the user information) is returned, you figure out if a user exists or not and creates one if it's new.

I also grok that the token issuer_id + sub are both required to determine a unique user from the point of an Auth Service.

Lastly, how do you prevent 'new account spam/abuse' ? I'm assuming that at some point in your Client (which checks for a local-storage token before each Rest API request because we need to stick some token in the bearer header) ...that when you decide to create a new user ... my REST Api (aka the Resource Server) will have an endpoint to create new users .. like POST /account/ .. so how do protect your server from getting spam'd new random POST's that create new accounts? IP+time-delay restriction?

where do we actually create the account in our Database?

Create a database table that includes an iss and sub column. Setup those columns as a unique compound key that represents a user. Insert user accounts in there.

So, can anyone explain how they use implicit flow and .. when a token (or more specifically, when OpenID Connect is used to get the user information) is returned, you figure out if a user exists or not and creates one if it's new?

It sounds like you already know the answer.

1. Parse the id_token.
2. Retrieve the iss and sub.
3. Check your app's table for that iss + sub key.
4. If it's there, then that user exists. If it isn't, then create the user.

From the spec:

Subject Identifier: Locally unique and never reassigned identifier within the Issuer for the End-User, which is intended to be consumed by the Client.

https://openid.net/specs/openid-connect-core-1_0.html

The iss and sub act as a unique compound key that represents the user. Here is an example id_token.

{
 alg: "RS256",
 kid: "1e9gdk7"
}.
{
 iss: "http://server.example.com",
 sub: "248289761001",
 aud: "s6BhdRkqt3",
 nonce: "n-0S6_WzA2Mj",
 exp: 1311281970,
 iat: 1311280970
}.
[signature]

Treat the iss + sub compound key in the same way that you would treat any other unique user identifier.

so how do protect your server from getting spam'd new random POST's that create new accounts?

Setup Cross-Origin Resource Sharing (CORS) restrictions, so that only your SPA's domain is allowed to POST to the /api/account endpoint.