* fix(apps): add type hints to whitelisted methods * fix(recorder): add type hints to whitelisted methods * fix(comments): add type hints to whitelisted methods * fix(oauth2): add type hints to whitelisted methods * fix(google_calendar): add type hints to whitelisted methods * fix(print): add type hints to whitelisted methods * fix(print_format_builder): add type hints to whitelisted methods * refactor(network_printer_settings): remove unused args * fix(document): add type hints to whitelisted methods * fix(user_settings): add type hints to whitelisted methods * fix(mapper): add type hints to whitelisted methods * fix(connected_app): add type hints to whitelisted methods * fix(google_contacts): add type hints to whitelisted methods * fix(frappecloud_billing): add type hints to whitelisted methods * test: rewrite test to fit the strict type check * fix(social_login_key): add type hints to whitelisted methods * fix(share): add type hints to whitelisted methods * fix(webhook): add type hints to whitelisted methods * fix(workflow): add type hints to whitelisted methods * fix(workflow main): add type hints to whitelisted methods * fix(workflow_action): add type hints to whitelisted methods * fix: flexible type hint * fix(client): add type hints to whitelisted methods * fix: fix some of the tighter types * fix(frappecloud_billing): add str typehint to whitelisted endpoint * fix: target_doc can be dict/json string --------- Co-authored-by: Ankush Menat <ankush@frappe.io> |
||
|---|---|---|
| .. | ||
| doctype | ||
| frappe_providers | ||
| workspace/integrations | ||
| __init__.py | ||
| google_oauth.py | ||
| oauth2.py | ||
| oauth2_logins.py | ||
| README.md | ||
| utils.py | ||
Integrations
OAuth 2
Frappe Framework uses oauthlib to manage OAuth2 requirements. A Frappe instance can function as all of these:
- Resource Server: contains resources, for example the data in your DocTypes.
- Authorization Server: server that issues tokens to access some resource.
- Client: app that requires access to some resource on a resource server.
DocTypes pertaining to the above roles:
- Common
- OAuth Settings: allows configuring certain OAuth features pertaining to the three roles.
- Authorization Server
- OAuth Client: keeps records of clients registered with the frappe instance.
- OAuth Bearer Token: tokens given out to registered clients are maintained here.
- OAuth Authorization Code: keeps track of OAuth codes a client responds with in exchange for a token.
- OAuth Provider Settings: allows skipping authorization.
[DEPRECATED]use OAuth Settings instead.
- Client
- Connected App: keeps records of authorization servers against whom this frappe instance is registered as a client so some resource can be accessed. Eg. a users Google Drive account.
- Social Key Login: similar to Connected App, but for the purpose of logging into the frappe instance. Eg. a users Google account to enable "Login with Google".
- Token Cache: tokens received by the Frappe instance when accessing a Connected App.
Features
Additional features over oauthlib that have implemented in the Framework:
- Dynamic Client Registration: allows a client to register itself without manual configuration by the resource owner. RFC7591
- Authorization Server Metadata Discovery: allows a client to view the instance's auth server (itself) metadata such as auth end points. RFC8414
- Resource Server Metadata Discovery: allows a client to view the instance's resource server metadata such as documentation, auth servers, etc. RFC9728
Additional Docs
Documentation of various OAuth2 features:
- How to setup OAuth 2?
- OAuth 2
- Token Based Authentication
- Using Frappe as OAuth Service
- Social Login Key
- Connected App
Warning
Some of these might be outdated, it is always recommended to check the code when in doubt.
OAuth Settings
A Single doctype that allows configuring OAuth2 related features. It is recommended to open the DocType page itself as each field and section has a sufficiently descriptive help text.
The settings allow toggling the following features:
- Authorization check when active token is present using the Skip Authorization field. Note: Keep this unchecked in production.
- Authorization Server Metadata Discovery: by toggling the Show Auth Server Metadata field.
- Dynamic Client Registration: by toggling the Enable Dynamic Client Registration field.
- Resource Server Metadata Discovery: by toggling the Show Protected Resource Metadata.
The remaining fields (in the Resource section) are used only when responding to requests on /.well-known/oauth-protected-resource
Regarding Public Clients
Public clients, for example an SPA, have restricted access by default. This restriction is applied by use of CORS.
To side-step this restriction for certain trusted clients, you may add their hostnames to the Allowed Public Client Origins field.