First pass on documentation for auth claims

[jdetter]

Description of Changes

This PR adds documentation for accessing auth claims in modules.

API and ABI breaking changes

This is a docs change.

Expected complexity level and risk

0

Testing

• All examples compile and have been tested working

[jsdt]

I took a look at the rust examples, and my main thoughts are that:

1. We should never use unwrap, and
2. We should probably have some example of a reducer other than the ClientConnected one.

[jsdt]

It's generally better to avoid using unwrap, so it's more obvious that it can't panic.

Suggested change

	let auth_ctx = ctx.sender_auth();
	let jwt = ctx.sender_auth()
	.jwt()
	.ok_or_else(|| "Client connected without JWT".to_string())?;

If you think having those branches is more readable, you can also use a match:

Suggested change

	let auth_ctx = ctx.sender_auth();
	let jwt = match ctx.sender_auth().jwt() {
	Some(jwt) => jwt,
	None => return Err("Client connected without JWT".to_string()),
	};
	let jwt = match ctx.sender_auth()
	.jwt()
	.ok_or_else(|| "Client connected without JWT".to_string())?;

[jsdt]

You could use claims.iss here instead of auth_ctx.jwt().unwrap().issuer().

[jsdt]

Using these auto_inc user ids in examples feels like it clashes with the identity that we are using in so many parts of our APIs.

[jsdt]

I like the example of roles. I think it could use useful to add an example of using this in a reducer to decide whether a client is allowed to do something, since these examples are only covering the initial connection right now.

[jsdt]

I'm not sure how useful these tables would be, since the reducers that would be enforcing any security rules would also have access to the email on the auth token. Having a table with email and role would make more sense to me.

Since the code in this example is computing the role from the email, we don't actually need to store any of the roles in tables. I think the main reason to have a user roles table would be to be able to set roles for different users via SQL or a different admin-only reducer.

[jsdt]

One weird aspect of this is that people using maincloud have auth from auth.spacetimedb.com, so this would mean that someone logged in with the creds needed to publish would not be able to use spacetime sql.

[jdetter]

#[table(name = admin)]
pub struct Admin {
    #[unique]
    pub ident: Identity,
}

// Add to on_connect
#[reducer(init)]
pub fn init(ctx: &ReducerContext) -> Result<(), String> {
    ctx.db.admin().insert(Admin{
        ident: ctx.sender
    });
    Ok(())
}

// Is the sender an owner of the db?
if ctx.db.admin().ident().find(ctx.sender).is_some() {
  return Ok(());
}
// Then check for google auth

// Note: check the audience here as well