Chapter 3 Access Tokens
Access tokens are a small but important part of Odoo portal and website behavior. They allow a document to be opened from a shared link even when the visitor does not have normal backend access rights to that document.
In daily implementation work, access tokens appear most often in shared quotations, sales orders, invoices, subscriptions, helpdesk tickets, and portal documents. Users may not see the technical model behind them, but they experience the result: a customer receives a link, clicks it, and opens the correct portal page.
What An Access Token Does
An access token is usually a unique value stored on a document and included in the shared URL. When the link is opened, Odoo checks whether the token in the URL matches the token on the document.
If the token is valid, Odoo can show the frontend portal page even if the visitor is not logged in as an internal user. If the token is missing, expired, or invalid, Odoo redirects the visitor to the login page or refuses access.
This mechanism allows Odoo to balance two needs:
| Need | How The Token Helps |
|---|---|
| Convenience | Customers can open a shared document from email without navigating the backend. |
| Security | The document is not public by default; the URL must contain the correct token. |
| Portal usability | External users can approve, sign, pay, or review documents from the website front end. |
Native Behavior
In native Odoo, a shared document commonly has one access token. Once generated, the token remains available until it is refreshed or replaced by the system.
This is easy to understand and works well for many ordinary portal flows. For example, a quotation can be sent to a customer, and the customer can open the quotation page, review the details, sign it, or pay online if the relevant options are enabled.
The limitation is that a single token is not enough when a company wants more precise control. For example:
| Scenario | Native Single-Token Limitation |
|---|---|
| Share the same order with multiple people | Everyone may use the same link, so individual tracking is weak. |
| Give different recipients different validity periods | The document-level token cannot easily represent different expiration dates. |
| Revoke one recipient's access only | Refreshing the document token may invalidate access for everyone. |
Implementation Notes
When explaining access tokens to customers, avoid treating them as ordinary passwords. A token link is closer to a controlled share link: anyone who has the valid link may be able to open the related portal page, depending on the model and controller logic.
In implementation, pay attention to these points:
| Point | Recommendation |
|---|---|
| Email delivery | Make sure the outgoing email domain and link domain are correct, especially in multi-company websites. |
| Portal permissions | Do not give external users unnecessary backend access just to let them see a document. |
| Link forwarding | Remind customers that forwarded links may expose the same portal document to others. |
| Expiration control | Use an extension if the business requires per-recipient validity periods. |
| Testing | Test shared links in a private browser window to simulate a real external visitor. |
Enhanced Token Management
For projects that require multiple tokens, recipient-level control, or expiration dates, Qingdao Ohm's portal extension can add token management on top of the native portal flow.
With enhanced token management, users can generate separate tokens for different partners, define expiration dates, and manage existing tokens from a technical list or the related sales order. This keeps the standard Odoo portal as the base while giving companies more control over shared documents.
Access tokens are not usually the first thing users notice in an Odoo website project, but they are one of the foundations behind a reliable customer portal. In the next chapter, we move from shared document links to mailing lists, another common website feature used to build long-term customer communication.