Created a db table for storing external api access tokens and create endpoint to add tokens

Currently, we use a db table called external_api_access_tokens to store the tokens to authenticate third parties like ORCID.

Since third parties return both access and refresh tokens, we should store both in the database with the user id. My recommendation is that we keep the same fields as the existing external_api_access_tokens db table.

CREATE TABLE external_api_access_tokens (
    id INT AUTO_INCREMENT PRIMARY KEY,
    user_id INT NOT NULL,
    external_service_name VARCHAR(255) NOT NULL,
    access_token VARCHAR(255) NOT NULL,
    refresh_token VARCHAR(255),
    expires_at DATETIME,
    revoked_at DATETIME,
    created_at DATETIME NOT NULL,
    updated_at DATETIME NOT NULL,
    INDEX idx_user_id (user_id),
    INDEX idx_external_service_name (external_service_name),
    INDEX idx_expires_at (expires_at),
    INDEX index_external_tokens_on_user_and_service (user_id, external_service_name)
);

Then we'll need to add an endpoints that the frontend can call when a user clicks to connect to ORCID. The redirect_uri for ORCiD should be a backend endpoint where the "auth code" is exchanged for an access token. The access token should then be stored in the "external_api_access_token" db table. When the user's Connections page loads, it will need to call the backend to know whether the user is connected or not.

We should follow the instructions provided by ORCiD for their 3-legged OAuth: https://info.orcid.org/documentation/api-tutorials/api-tutorial-get-and-authenticated-orcid-id/

Start by inspecting the existing external_api_access_tokens table and the backend endpoint surface, then read the linked ORCID three-legged OAuth instructions. Map the token exchange, storage, and connection-status requirements before choosing the affected entry points. Done means users can connect ORCID, have access and refresh tokens stored with expiry data, and retrieve their connection status.