Add API token management system

[ba88im]

Summary

• Adds a new ApiToken model with course scoping, user association, expiration, usage tracking (last_used_at), read/write permissions, and secure token storage (SHA-256 digest, never plaintext)
• Adds an instructor-only "API Tokens" management page (view + revoke) accessible from the course sidebar
• Updates the CSV export endpoint to support both the new token system and the legacy readonly_api_token for backward compatibility
• Includes a rake task (rake api_tokens:migrate_legacy_tokens) to migrate existing legacy tokens to the new system, linked to the auto-approval system user

Context

Previously, each course had a single readonly_api_token stored in plaintext on the courses table — no user association, no expiration, no management UI. This PR replaces that with a proper token system that supports multiple tokens per course, each scoped to a user with configurable permissions.

Phase 1 (this PR): model + view/delete UI + migration tooling
Phase 2 (future): token creation UI

Related: #155 (Slack approve/deny links will use read+write tokens)

Test plan

• Run rails db:migrate and verify api_tokens table is created
• Run bundle exec rspec spec/models/api_token_spec.rb — model tests pass
• Run bundle exec rspec spec/controllers/api_tokens_controller_spec.rb — controller tests pass
• Navigate to /courses/:id/api_tokens as instructor — see token table
• Verify students cannot access the API Tokens page
• Revoke a token and verify it shows as revoked
• Verify CSV export still works with legacy readonly_api_token
• Run rake api_tokens:migrate_legacy_tokens and verify tokens are migrated

[cycomachead]

This is looking great. I have not tested this, but I have a few general comments:

• The column name read_write as a boolean t/f is very confusing. "Is it a read or a write token? -> "Yes!". The most clear thing seems to me to be read_only with a default of TRUE and not false, for safety.
• It is not clear to me if we need both created_by and user on a token? Presumably this only makes sense if someone can create tokens on another user's behalf. I don't think we need this feature, and perhaps just having a user_id is simpler a good enough.
• I appreciate the fallback code and migration paths. I think we can simplify this.
• We should accept the readonly_api_token query parameter, but I don't think we need to look up tokens on the courses table. We should be able to assume those are all migrated and will be migrated at deploy time. I would also add a comment that says something like:

# April 2026 - We migrated X Y Z
# Dec 2026 (or later): It is safe to remove the remove the deprecated query parameter and this comment.

Bigger Questions: Current CSV/Google Sheets Flow

Right now, on the All Requests view there buttons that give users links which include the API token pre-filled in the URL. These seem incompatible with this new system because the plaintext/sharable form of the URL is only ever designed or created once.

So, in order to deploy this and merge, I think we have two options:

• We either need to save the pre-digested form of a token in the db. This does have security implications.
• We need to re-architect how tokens are created and explain to users that the URL / Token will only ever be display once, which means they probably need to click twice to get a new URL/token. (e.g. once to start the process and then once to confirm.)

As I am looking at this, since we don't delete the tokens (yet) from the courses controller, we can migrate the tokens, but still display reading them from the existing table and the follow up PRs can handle changing how that page works?

[cycomachead]

This is a smaller change, but I wonder if we can just use controller_name here? This is an existing pattern, but I wonder if it's actually necessary to set @side_nav

[cycomachead]

Side note, I wonder if this endpoint should always return a CSV.
In the case of an error maybe it should return something like

Error, Status, Message
True,401|404|etc,the current messages...

This would make debugging things easier when they co wrong...

[cycomachead]

I don't think we need this type of fallback, since we can read from the new table.

But genuinely curious here: Have you taken 161 or did you know to use secure compare?
It's probably a good thing to do, but notably isn't done in the process of now making a digest+looking up a token from the new table. Did a LLM just suggest this method or put it in automatically?

I wonder if it really is OK not to use securecompare on the new tokens lookup because we're doing the digest (which takes sometime, but I don't know if's actually timing-attack safe) THEN doing a db query, which should be safer because it's computationally less predictable?

Might be interesting to ask an LLM if it'd make much of a difference. Tbh, this is only of those small, but annoying, easy to forget pieces of security and one we don't talk about much.

[cycomachead]

This is where I wonder if there's any susceptibility to a timing attack or other concern that would have necessitated SecureCompare?

(Not that this type of vulnerability is really a high concern for this kind of application... but I am curious)

[cycomachead]

Small thing, but I think it's fine to render the table and 0 rows.

We can choose to put the no tokens message below the table still, but I think we can simplify the view code.

[cycomachead]

This is where I wonder if we can actually just write controller_name == 'api_tokens or something like this?

Side note, I am thinking we will want to find a place to link API tokens that is more advanced than a top-level link in the sidebar, but this is good for now.