Send the credential type to Orbit in the query JWT

What does this MR do and why?

Orbit query analytics cannot tell a personal access token from an OAuth token, so scripts and bots look like any other API caller unless you search the Rails logs. The Orbit JWT now carries a token_type claim, and Orbit records it on each query event next to the user_type claim Rails already sends.

{ "user_type": "project_bot", "token_type": "personal_access_token" }

token_type is personal_access_token (also group, project, and service account tokens) or oauth_access_token (also the stateless Duo Workflow and IAM OAuth tokens). A browser session sends no claim.

References

• Orbit consumer: gitlab-org/orbit/knowledge-graph!3082 (merged)
• Snowplow schema: https://gitlab.com/gitlab-org/iglu/-/merge_requests/220 (merged)

Screenshots or screen recordings

Not applicable: no UI change. The claim is in the snippet above.

How to set up and validate locally

1. In a Rails console, build a token for a request with a personal access token and decode it:

   user = User.first
   context = Analytics::KnowledgeGraph::RequestContext.new(source_type: 'rest', token_type: 'personal_access_token')
   token = Analytics::KnowledgeGraph::JwtAuth.generate_token(user: user, request_context: context)
   JWT.decode(token, Analytics::KnowledgeGraph::JwtAuth.secret, true, algorithm: 'HS256').first.slice('user_type', 'token_type')
   # => {"user_type"=>"human", "token_type"=>"personal_access_token"}

2. Call POST /api/v4/orbit/query with a personal access token and check the GKG server log or the gkg_query_executed event for token_type.

MR acceptance checklist

Evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.

Related to gitlab-org/orbit/knowledge-graph#310 (closed)