Authentication roadmap

[sbidoul]

This issue is consolidating the efforts around shopinvader frontend partner authentication, in base_rest and fastapi services, and with the new cookie-based anonymous partner concept discussed in Valencia.

• auth_jwt
  • 14.0
  • 16.0
  • a mechanism to configure JWT validators
  • Odoo authentication methods based on JWT Authorization headers (auth_jwt, auth_public_or_jwt)
  • mechanism to find an Odoo partner from the JWT payload and set it in request.jwt_partner_id
  • mechanism to find an Odoo user to run the request (static by default)
  • optional mechanism to convert the JWT token into a http-only cookie for simpler and more secure frontend implementation: [16.0] auth_jwt: add cookie mode OCA/server-auth#520
  • cookie mode 14.0: [14.0][MIG] backport auth_jwt and auth_jwt_demo improvements from 16.0 OCA/server-auth#531
• base_rest_auth_jwt
  • 14.0
  • 16.0: to migrate
  • expose the JWT authentication mechanism in the openapi spec generated by base_rest
  • provide a standard component to obtain the authenticated partner
• fastapi_auth_jwt
  • 14.0: [14.0][PORT] backport fastapi_auth_jwt, fastapi_auth_jwt_demo from 16.0 OCA/rest-framework#355
  • 16.0: [16.0][ADD] fastapi_auth_jwt, fastapi_auth_jwt_demo OCA/rest-framework#347
  • bridges fastapi with auth_jwt
  • provides FastAPI dependencies to authenticate with auth_jwt validators and obtain the authenticated partner
• shopinvader_anonymous_partner
  • 14.0: [14.0][PORT] shopinvader_anonymous_partner, shopinvader_fastapi_auth_jwt from 16.0 #1378
  • 16.0: [16.0][ADD] shopinvader_anonymous_partner, shopinvader_fastapi_auth_jwt #1366
  • mechanism to create and retrieve anonymous partners, establish the anonymous partner session with a cookie
  • this one is meant to use with SPA frontends, not locomotive
  • ??? which is the part that provides the equivalent feature with locomotive?
• shopinvader_auth_jwt
  • 14.0
  • 16.0: [16.0] [MIG] shopinvader_auth_jwt #1418
  • bridges auth_jwt and shopinvader
  • provides the /shopinvader_jwt endpoint
  • ??? why does this not depend on base_rest_auth_jwt? => because of shopinvader.partner, but...
  • ??? should we make this depend on shopinvader_anonymous_partner and return the anonymous partner if there is one?
• shopinvader_fastapi_auth_jwt
  • 14.0: [14.0][PORT] shopinvader_anonymous_partner, shopinvader_fastapi_auth_jwt from 16.0 #1378
  • 16.0: [16.0][ADD] shopinvader_anonymous_partner, shopinvader_fastapi_auth_jwt #1366
  • provide an authenticated_partner FastAPI dependency that returns either the authenticated partner from fastapi_auth_jwt if the request is authenticated, or the anonymous partner from shopinvader_anonymous_partner, or raise a 401 is both failed. The idea here is that an anonymous partner obtains the same access as a regular partner (i.e. see own records - cart, SO, invoices, etc).

[sbidoul]

@lmignon @hparfr @sebastienbeau things are taking shape on the authentication front following our recent discussions in Valencia. cc/ @simahawk @acsonefho @xavier-bouquiaux @Cedric-Pigeon @marielejeune @AnizR

This is the simplest I can imagine so far... and it's still too complex to my taste, but that's probably the price to pay to deploy those API in Odoo, ability to extend these API, have auth configuration per database, and compatibility between base_rest and fastapi services. Suggestions welcome. If you want to do a call to discuss with higher bandwidth, let me know.

[sebastienbeau]

Thanks for opening this issue to track all the work.
I seem to be the right solution, indeed it's a lot of module, but it's the only way to have the two API working on the same version without breaking everything.
It's ok for me

[lmignon]

shopinvader_auth_jwt
??? why does this not depend on base_rest_auth_jwt?

IMO it should. But it could be the result of the additional layer introduced by shopinvader on top of res.partner: shopinvader.partner. The authentication is also used to know from which website the request come from and to find the related shopinvader.backend. All this need a big clean up but it seems difficult without break breaking existing code if we do it.

shopinvader_auth_jwt
??? should we make this depend on shopinvader_anonymous_partner and return the anonymous partner if there is one?

🤔 🤔 🤔 The shopinvader_anonymous_partner create a res.partner record... But the authentication is done by a lookup on the shopinvader.partner model. All this seems more and more unmanageable. A cleanup is required to get rid in a way or another of shopinvader.partner.

ping @sebastienbeau @simahawk @acsonefho

[sbidoul]

@lmignon my understanding is that shopinvader.partner is only used to find the res.partner for a given site. But once we have found the res.partner, it is the one we use. If correct it means that we don't need a shopinvader.partner for anonymous partners.

A given anonymous partner could have access to different sites, that should not be a problem.

So maybe the issue is not so big after all.

[sbidoul]

Everything is backported to 14. Juste one test CI issue to resolve in #1378.
If there are enough reviews (on the PRs linked here and their dependents) I can merge until tomorrow evening.

[sbidoul]

Ok, everthing works. I think the last bit missing is to integrate the cookie mode with base_rest_auth_jwt.

[sbidoul]

Ok, everthing works. I think the last bit missing is to integrate the cookie mode with base_rest_auth_jwt.

Actually since the cookie mode is implemented in auth_jwt, base_rest_auth_jwt and shopinvader_auth_jwt should inherit it automatically. To be tested.

So unless some base_rest services require the new anonymous partner mechanism, this is complete.

To unlock the merge chain, a second review in OCA/server-auth#531 is needed.