Security News
PyPI Introduces Digital Attestations to Strengthen Python Package Security
PyPI now supports digital attestations, enhancing security and trust by allowing package maintainers to verify the authenticity of Python packages.
@authx/authx
Advanced tools
This is AuthX. It's named AuthX because it's an "exchange" of sorts, consolidating identities from several upstream authorities into a single identity for downstream clients. AuthX uses the OAuth2 framework in both directions, and adds a robust access con
This is AuthX. It's named AuthX because it's an "exchange" of sorts, consolidating identities from several upstream authorities into a single identity for downstream clients. AuthX uses the OAuth2 framework in both directions, and adds a robust access control system, based on the AuthX scope spec.
Concepts | Development | Scopes
AuthX is designed for a scenario in which a RESOURCE needs to restrict access to all or part of its functionality. A CLIENT app, acting on behalf of a User can retreive an OAuth token from AuthX, which can be passed to the RESOURCE with any request.
╔══════════════════════════════════════════╗
║ ┌───────────┐ ║
║ │ AUTHORITY │ ║
║ └─────┬─────┘ ║
║▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓│▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓║
║ ┌────────────┐ ┌─────┴─────┐ ║
║ │ Credential ├─┤ Authority │ ║
║ └───┬────────┘ └───────────┘ ║
║ ┌───┴──┐ Authentication ║
║░░░│ User │░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░║
║ └─┬──┬─┘ ┌──────┐ ║
║ │ └────────────────┤ Role │ ║
║ ┌┴──────┐ ┌────────┐ └──────┘ ║
║ │ Grant ├─┤ Client │ ║
║ └───────┘ └───┬────┘ Authorization ║
║▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓│▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓║
║ ┌───┴────┐ ┌──────────┐ ║
║ │ CLIENT ├─┤ RESOURCE │ ║
║ └────────┘ └──────────┘ ║
╚══════════════════════════════════════════╝
A user is the central component, and represents a source of agency, either human
or machine
.
A resource is anything which requires an AuthX token to perform an action.
A client uses AuthX to act on behalf of a user.
A grant contains the set of scopes for which a client's can act on a user's behalf.
An authorization contains the set of scopes that will be encoded in a token and passed to a resource by a client.
A role bestows its scopes to every user it includes.
An authority is a mechanism for authentication, and provides the configuration for corresponding units of code called strategies. Several strategies are included by default:
Credentials connect users to authorities. A user can have multiple credentials of the some authorities (multiple emails, for example), or be limited to one (such as a password).
These scripts can be run using npm run <script>
; when relevant, the following environment variables can be set to modify their behavior:
PORT
: HTTP port to listenPGHOST
: postgres hostPGPORT
: postgres portPGUSER
: postgres userPGPASSWORD
: postgres passwordformat
Use prettier to format the code in this package.
lint
Check the contents of this package against prettier and eslint rules.
prepare
Build the files from /src
to the /dist
directory with optimizations.
prepare:development
Build the files from /src
to the /dist
directory, and re-build as changes are made to source files.
start
Start a web server that runs AuthX.
start:development
Start a web server that runs AuthX and reloads as its source files change. Use the PORT
environment variable to specify a port.
test
Run all tests from the /dist
directory.
test:development
Run all tests from the /dist
directory, and re-run a test when it changes.
This holds the source code for AuthX.
The compiled and bundled code ends up here for distribution. This is ignored by git.
AuthX uses its own authorization system to restrict access to its resources. A scope is divided into three parts:
authx
or identity
or authx.dev
)For an AuthX resource, the context is always in the following format:
v2.(type).(authority_id).(authorization_id).(client_id).(credential_id).(role_id).(user_id)
When checking for the ability to perform an action on an entity, the entity's ID and the IDs of related entities are present on the compared scope. When creating a new entity, only the IDs of related entities will be present, and the position of the entity' ID will be empty, even if an ID is specified for the entity in its creation request.
Given an entity type, relevant IDs will be present in the context:
type | authority_id | authorization_id | client_id | credential_id | grant_id | role_id | user_id |
---|---|---|---|---|---|---|---|
authority | ✪ | ||||||
authorization | ✪ | ● | ○ | ● | |||
client | ✪ | ||||||
credential | ● | ✪ | ● | ||||
grant | ● | ✪ | ● | ||||
role | ✪ | ||||||
user | ✪ |
For an AuthX resource, the action is always in the following format:
(basic).(details).(scopes).(secrets).(users)
In each position, an r
designates the ability to perform reads, a w
designates the ability to write, and (per normmal scope semantics) a *
designates both.
To create a new entity, a value of *
is required in each relevant position. For example, the following scope represents the ability to create a new client:
authx:v2.client.......:*..*.*.
type | basic | details | scopes | secrets | users |
---|---|---|---|---|---|
authority | ✪ | ● | |||
authorization | ✪ | ● | ● | ||
client | ✪ | ● | |||
credential | ✪ | ● | |||
grant | ✪ | ● | ● | ||
role | ✪ | ● | ● | ||
user | ✪ | ◯ |
r
will be checked for reads.r
will be checked for reads and a w
will be checked for writes.r
or w
in this position.Users must have the following scopes to use OAuth:
authx:v2.client...*....:r....
authx:v2.user.......{current_user_id}:r....
authx:v2.grant...{current_client_id}..{current_grant_id}..{current_user_id}:*..*.*.
authx:v2.authorization..*.{current_client_id}..{current_grant_id}..{current_user_id}:*..*.*.
The following scopes are implicit in an OAuth request:
authx:v2.user.......{current_user_id}:r....
authx:v2.grant...{current_client_id}..{current_grant_id}..{current_user_id}:r..*.*.
authx:v2.grant...{current_client_id}..{current_grant_id}..{current_user_id}:w...*.
authx:v2.authorization..*.{current_client_id}..{current_grant_id}..{current_user_id}:*..*.*.
FAQs
This is AuthX. It's named AuthX because it's an "exchange" of sorts, consolidating identities from several upstream authorities into a single identity for downstream clients. AuthX uses the OAuth2 framework in both directions, and adds a robust access con
We found that @authx/authx demonstrated a healthy version release cadence and project activity because the last version was released less than a year ago. It has 2 open source maintainers collaborating on the project.
Did you know?
Socket for GitHub automatically highlights issues in each pull request and monitors the health of all your open source dependencies. Discover the contents of your packages and block harmful activity before you install or update your dependencies.
Security News
PyPI now supports digital attestations, enhancing security and trust by allowing package maintainers to verify the authenticity of Python packages.
Security News
GitHub removed 27 malicious pull requests attempting to inject harmful code across multiple open source repositories, in another round of low-effort attacks.
Security News
RubyGems.org has added a new "maintainer" role that allows for publishing new versions of gems. This new permission type is aimed at improving security for gem owners and the service overall.