Oso is a batteries-included framework for building authorization in your application.

Overview

Oso

Development GitHub release (latest SemVer) Go version Maven version NPM version PyPI version RubyGems version Crates.io version Slack

What is Oso?

Oso is a batteries-included framework for building authorization in your application.

With Oso, you can:

  • Model: Set up common permissions patterns like role-based access control (RBAC) and relationships using Oso’s built-in primitives. Extend them however you need with Oso’s declarative policy language, Polar.
  • Filter: Go beyond yes/no authorization questions. Implement authorization over collections too - e.g., “Show me only the records that Juno can see.”
  • Test: Write unit tests over your authorization logic now that you have a single interface for it. Use the Oso debugger or REPL to track down unexpected behavior.

Oso offers libraries for Node.js, Python, Go, Rust, Ruby, and Java.

Our latest creation Oso Cloud (Preview) makes authorization across services as easy as oso.authorize(user, action, resource). Learn about it.

Documentation

Community & Support

If you have any questions on Oso or authorization more generally, you can join our engineering team & hundreds of other developers using Oso in our community Slack:

Button

Share your story

We'd love to hear about your use case and experience with Oso. Share your story in our Success Stories issue or fill out this form for some Oso swag.

Development

Core

Oso's Rust core is developed against Rust's latest stable release.

Language libraries

Oso's language libraries can be developed without touching the Rust core, but you will still need the Rust stable toolchain installed in order to build the core.

To build the WebAssembly core for the Node.js library, you will need to have wasm-pack installed and available on your system PATH.

Language requirements

To work on a language library, you will need to meet the following version requirements:

  • Java: 10+
    • Maven: 3.6+
  • Node.js: 12.20.0+
    • Yarn 1.22+
  • Python: 3.6+
  • Ruby: 2.4+
    • Bundler 2.1.4+
  • Rust: 1.46+
  • Go: 1.14+

Contributing & Jobs

See: CONTRIBUTING.md.

If you want to work on the Oso codebase full-time, visit our jobs page.

License

See: LICENSE.

Issues
  • Trace Logging

    Trace Logging

    Trace output during execution of a query that shows what's happening. Should make debugging a bit easier.

    Notable features include.

    • Showing all the applicable rules when querying a call. This shows which rules and the order they will be tried after filtering and sorting has been done.
    • Showing Queries, Unifys, Matches, Comparisons and Math operations.
    • ShowingFFIi lookups and the results that come back.
    • Showing relevant bindings (bindings for variables used in the expressions being traced) alongside so it's easier to see what's happening.

    Looks something like this.

    query> f(1);
    [trace]   QUERY: 'f(1)', BINDINGS: {}
    [trace]     FILTERING RULES
    [trace]       UNIFY: '1' = '_x_4', BINDINGS: {}
    [trace]       UNIFY: '1' = '_x_6', BINDINGS: {}
    [trace]       UNIFY: '1' = '_x_7', BINDINGS: {}
    [trace]     SORTING RULES
    [trace]     APPLICABLE_RULES: [
    [trace]       f(x) if new (Foo{x: x}, _instance_2) and .(_instance_2, foo(), _value_1) and _value_1 = x;
    [trace]       f(x) if x = 1;
    [trace]       f(x) if x + 1 and _op_3 == 2;
    [trace]     ]
    [trace]     RULE:
    [trace]     f(x) if
    [trace]       new Foo{x: x}.foo() = x
    [trace]     UNIFY: '1' = '_x_10', BINDINGS: {}
    [trace]       QUERY: 'new (Foo{x: _x_10}, _instance_2_11) and .(_instance_2_11, foo(), _value_1_12) and _value_1_12 = _x_10', BINDINGS: {"_x_10": "1"}
    [trace]         QUERY: 'new (Foo{x: _x_10}, _instance_2_11)', BINDINGS: {"_x_10": "1"}
    [trace]           UNIFY: '_instance_2_11' = 'Foo{x: 1}', BINDINGS: {}
    [trace]         QUERY: '.(_instance_2_11, foo(), _value_1_12) and _value_1_12 = _x_10', BINDINGS: {"_instance_2_11": "Foo{x: 1}", "_x_10": "1"}
    [trace]           QUERY: '.(_instance_2_11, foo(), _value_1_12)', BINDINGS: {"_instance_2_11": "Foo{x: 1}"}
    [trace]             LOOKUP: Foo{x: 1}.foo()
    [trace]             => 2
    [trace]           QUERY: '_value_1_12 = _x_10', BINDINGS: {"_x_10": "1", "_value_1_12": "2"}
    [trace]             UNIFY: '_value_1_12' = '_x_10', BINDINGS: {"_value_1_12": "2", "_x_10": "1"}
    [trace]             UNIFY: '2' = '1', BINDINGS: {}
    [trace]             LOOKUP: Foo{x: 1}.foo()
    [trace]             => No more results.
    [trace]     RULE:
    [trace]     f(x) if
    [trace]       x = 1
    [trace]     UNIFY: '1' = '_x_13', BINDINGS: {}
    [trace]       QUERY: '_x_13 = 1', BINDINGS: {"_x_13": "1"}
    [trace]         UNIFY: '_x_13' = '1', BINDINGS: {"_x_13": "1"}
    [trace]         UNIFY: '1' = '1', BINDINGS: {}
    True
    [trace]     RULE:
    [trace]     f(x) if
    [trace]       x + 1 == 2
    [trace]     UNIFY: '1' = '_x_14', BINDINGS: {}
    [trace]       QUERY: '_x_14 + 1 and _op_3_15 == 2', BINDINGS: {"_x_14": "1"}
    [trace]         QUERY: '_x_14 + 1', BINDINGS: {"_x_14": "1"}
    [trace]           MATH: '1' + '1' = '_op_3_15', BINDINGS: {}
    [trace]           UNIFY: '2' = '_op_3_15', BINDINGS: {}
    [trace]         QUERY: '_op_3_15 == 2', BINDINGS: {"_op_3_15": "2"}
    [trace]           CMP: '2' == '2', BINDINGS: {}
    True
    query>
    
    opened by saolsen 19
  • refactor: Clarify error when right_path exists

    refactor: Clarify error when right_path exists

    Fixes #1552

    This commit catches the assertion error when verifying the right_path does not exist when a path has been identified on the left side of the policy. This refactor was made to better clarify the cause of the error for developers who may not be familiar with the technical limitations of the current SQLAlchemy integration.

    In my case, I had assumed that the use of foreign keys and paths on both sides would be more performant, and thus the best choice for a policy, when writing the authorization rules. The resulting error didn't include any context about what was wrong with the policy I had written. This commit aims to address this by providing a best effort guess to provide a starting point for developers to debug the policy issue themselves.

    PR checklist:

    • [ ] Added changelog entry.
    opened by kkirsche 13
  • __dirname is not defined in ES module scope

    __dirname is not defined in ES module scope

    ReferenceError: __dirname is not defined in ES module scope

    Unfortunately, oso appears to have trouble running when I build it as part of an ESM project because it references __dirname in certain parts of the code below:

    // [email protected]/node_modules/oso/dist/src/polar_wasm_api.js
    var path2 = __require("path").join(__dirname, "polar_wasm_api_bg.wasm");
    

    In my own code, where I load the .polar files, I work around this issue using the ESM recommended approach:

    import path from 'path';
    import { fileURLToPath } from 'url';
    
    const dirname = path.dirname(fileURLToPath(import.meta.url));
    
    await oso.loadFiles([path.resolve(dirname, 'main.polar')]);
    
    opened by pheuter 12
  • Derive `PolarClass` on Rust enums

    Derive `PolarClass` on Rust enums

    • [ ] PolarClass may now be derived on Rust enums.

    Hello :wave:

    I'm attempting to add support for Rust enums on the #[derive(PolarClass)] proc macro. This involves having the procedural macro generate code to store each enum variant on the Class that is being constructed. A loop in register_class then registers each constant.

    I sought to keep the API as simple as possible such that someone looking to add this functionality in their Rust project only needs to add #[derive(PolarClass)] onto their enums (thanks to @joshrotenberg for his input on this 🙂 ). However, this doesn't quite work; I'm hoping some additional eyes on it will help.

    The core of the problem seems to be fact that the constants are initially stored on the class as trait objects. Those are then passed around a few times before they get handed to register_constant. The compiler complains about the size of the trait objects not being known. I believe there are ways of handling this in nightly Rust, but I'm not sure what the pattern for addressing this is on stable.

    There's also the distinct possibility that I'm missing something simple 🙂

    opened by seanchen1991 12
  • isort, slight docstring formatting

    isort, slight docstring formatting

    Hello again :slightly_smiling_face: I've just gone for the auto-formatting route this time, except for one change.

    I've run isort & Black over all of the Python version of Oso (in that order,) removed the newlines under a few function docstrings that had them as per PEP 257. Black, as far as I know, doesn't have any guide on these, so it shouldn't interfere with anything.

    Now, for the manual change - I've removed the newlines between :param:s in oso/oso.py, as they weren't anywhere else - for consistency's sake and all that. Also extra newlines at the end of 2 docstrings in that same file.

    I do hope nothing breaks this time.

    opened by tomashozman 11
  • Fix file loading issue with Ruby gem - Fixes osohq/oso#1089

    Fix file loading issue with Ruby gem - Fixes osohq/oso#1089

    Here's a small fix to the Ruby gem for Oso that wasn't loading as expected out of the box. It fixes https://github.com/osohq/oso/issues/1089

    I wasn't able to find an applicable changelog file to register this. Nor did I know if I was supposed to bump the version in the code. Please let me know if this solution works.

    Since it's my first time contributing please give me instructions on accepting the contributors agreement.

    Thank you for Oso and the help on Slack!

    Docs 
    opened by davidpelaez 10
  • Memory Leak in Golang

    Memory Leak in Golang

    Hi OsoHQ,

    Been enjoying the library, and I hope to use it for an authorization service, however I believe I found a memory leak in the Golang library.

    Setup

    I was able to reproduce using the oso-go-quickstart example. I forked that repo and the only changes I made were:

    • upgraded to the latest oso v0.11.3 -> v0.12.3 (https://github.com/bhb603/oso-go-quickstart/blob/main/go.mod#L5)
    • added a policy:
      allow(actor: String, "GET", expense: Expense) if  
              expense.SubmittedBy = actor;
      
    • Dockerized the app and deployed it to a kubernetes cluster with this simple deployment (my ultimate use case would be to deploy in kubernetes, which is why I replicated that here)

    Testing

    I have some load-testing tooling which can generate requests against the service. Since this quickstart example only has one endpoint, it just requests:

    curl -H "user: [email protected]" http://oso-go-quickstart.oso:5050/expenses/1
    

    Which would check oso.IsAllowed(User("[email protected]"), "GET", expense) and return:

    HTTP/1.1 200 OK
    Content-Length: 40
    Content-Type: text/plain; charset=utf-8
    
    Expense{{500 coffee [email protected]}}
    

    Results

    Memory Usage increases linearly when the service is under load, until it reaches the limit I set for the container (256M) at which point Kubernetes kills the container (OOMKIlled) and it restarts, producing the saw tooth graph below.

    The rate of memory increase is proportional to the load (reqs per second), i.e. it increases ~2.5x faster when I was hitting it at 25rps vs 10rps, and flattens out with 0rps.

    Memory usage under load: Containers___Datadog

    More Metrics: image

    opened by bhb603 10
  • Diff docs on PR run.

    Diff docs on PR run.

    Add a job that looks for changes in the docs made by a diff by building the docs against the branch and base branch.

    If there are changes, will comment on the PR, as in #937 and require a comment to acknowledge the changes (you must manually re-run the job). The intent of this is to catch PRs that inadvertently break the docs, like changes to code included in code snippets.

    If you make a PR changing the docs intentionally, just comment "Docs changes ok" after uploading, and the job will pass on the first run.

    If you don't make any changes to the docs (#936), the job also passes, with no comment required.

    PR checklist:

    • [ ] Added changelog entry.
    opened by dhatch 10
  • Python `sqlalchemy-oso` for SQLAlchemy 1.4.x?

    Python `sqlalchemy-oso` for SQLAlchemy 1.4.x?

    Hi!

    Thanks for that awesome work on the Oso Framework! We are really enjoying working with it!

    Currently, we are evaluating whether the sqlalchemy-oso library would fit our needs. Are there any plans regarding the new SQLAlchemy 2 update?

    Trying to include it in our project leads to the following error message:

    Because sqlalchemy-oso (0.6.0) depends on sqlalchemy (>=1.3.20,<1.4.0) and no versions of sqlalchemy-oso match >0.6.0,<0.7.0, sqlalchemy-oso (>=0.6.0,<0.7.0) requires sqlalchemy (>=1.3.20,<1.4.0).

    Would love to hear from you!

    opened by moon-bits 10
  • (Java): Support M1

    (Java): Support M1

    • Bumps jnr-ffi to a newer version with Apple Silicon support.
    • Updates release workflow to build a fat (x86_64 + aarch64) .dylib and to use that in the .jar build

    Fixes the issue I mentioned in https://github.com/osohq/oso/issues/808#issuecomment-1023495977 (at least partially?).

    ~With the newer version I was able to build the .jar on a M1 machine and the final resulting .jar ran as expected with a aarch64 JRE. However the resulting .jar didn't run on the x86 JRE anymore (though I guess that is expected behavior).~

    ~Not sure how the .dylib for the release build is built (as the java Makefile references a debug build and specificlally makes a note that it shouldn't be used in release builds?), but I would assume that for properly building a fat .jar some additional step of cross-compiling and building a fat .dylib might be required.~

    EDIT: updated PR to include a build of a fat .dylib

    opened by hobofan 9
  • POLAR_LOG=0 should disable tracing

    POLAR_LOG=0 should disable tracing

    The documentation indicates that POLAR_LOG=1 enables tracing. Intuitively you would think that POLAR_LOG=0 disables tracing, particularly if you use the setting in a dotfile/docker-compose.yaml etc.

    However, it seems that POLAR_LOG just needs to be set to anything to enable tracing, and to be unset to disable tracing. I've tested this with the go, node, python and rust libraries, and it's the same with all four:

    Here's an example using the node library:

    ❯ which oso
    /Users/alexhafner/.volta/bin/oso
    ❯ echo $POLAR_LOG
    0
    ❯ oso
    query> 1+2=3
    [debug]   QUERY: 1 + 2 = _op_1 and _op_1 = 3, BINDINGS: {}
    [debug]     QUERY: 1 + 2 = _op_1, BINDINGS: {}
    [debug]     QUERY: _op_1 = 3, BINDINGS: {_op_1 = 3}
    true
    query> %
    ❯ unset POLAR_LOG
    ❯ oso
    query> 1+2=3
    true
    query> %
    ❯ export POLAR_LOG=foo
    ❯ oso
    query> 1+2=3
    [debug]   QUERY: 1 + 2 = _op_1 and _op_1 = 3, BINDINGS: {}
    [debug]     QUERY: 1 + 2 = _op_1, BINDINGS: {}
    [debug]     QUERY: _op_1 = 3, BINDINGS: {_op_1 = 3}
    true
    query>
    

    This was tested on main while reviewing the changes from https://github.com/osohq/oso/pull/1115

    It would be helpful for developers if tracing could be disabled by setting POLAR_LOG=0.

    opened by alexhafner 9
  • Refactor/type hints

    Refactor/type hints

    This merge request expands existing type hints. The primary focus of this merge request is on the public authorization API and the calls that this API reaches down to

    The use of object instead of Any may be a bit odd at first, but this is meant to better conform to the recommendations of the Python team managing type information. object is for when the code can accept any object for use, but we want errors if it's misused. Any disables error checking in a way that's a bit hard to detect a first.

    See this for a breakdown from some of their team: https://github.com/python/typeshed/pull/8469#issuecomment-1203116838

    PR checklist:

    • [ ] Added changelog entry.
    opened by kkirsche 1
  • Unable to use REPL on WSL CentOS on Windows

    Unable to use REPL on WSL CentOS on Windows

    REPL crash on any command:

    repl.ts

    import 'reflect-metadata'
    import 'module-alias/register'
    
    import { oso } from './oso'
    
    oso.repl().then(() => console.log('done'))
    
    [[email protected] backend]# npx ts-node src/authz/repl.ts 
    query> done
    query> debug()
    QUERY: debug(), BINDINGS: {}
    
    001: debug()
         ^
    
    true
    debug> help
    
    /root/dev/baas/web/backend/node_modules/.pnpm/[email protected]/node_modules/oso/dist/src/polar_wasm_api.js:677
        throw new Error(getStringFromWasm0(arg0, arg1));
              ^
    Error: null pointer passed to rust
        at module.exports.__wbindgen_throw (/root/dev/baas/web/backend/node_modules/.pnpm/[email protected]/node_modules/oso/dist/src/polar_wasm_api.js:677:11)
        at wasm://wasm/004b73ea:wasm-function[1859]:0x10c9c0
        at wasm://wasm/004b73ea:wasm-function[1860]:0x10c9cd
        at wasm://wasm/004b73ea:wasm-function[1347]:0x100d43
        at Query.debugCommand (/root/dev/baas/web/backend/node_modules/.pnpm/[email protected]/node_modules/oso/dist/src/polar_wasm_api.js:366:14)
        at Interface.<anonymous> (/root/dev/baas/web/backend/node_modules/.pnpm/[email protected]/node_modules/oso/src/Query.ts:360:30)
        at Interface.emit (node:events:537:28)
        at Interface.emit (node:domain:482:12)
        at Interface.[_onLine] [as _onLine] (node:internal/readline/interface:425:12)
        at Interface.[_line] [as _line] (node:internal/readline/interface:886:18)
    
    opened by NexZhu 0
  • Broken implementation of the oso::PolarClass derive macro

    Broken implementation of the oso::PolarClass derive macro

    I am using both diesel 2.0 and oso in a project, if I define a struct:

    #[derive(PolarClass)]
    #[diesel(table_name = accounts)]
    pub struct Account {
        #[polar(attribute)]
        pub id: Uuid,
        pub email: String,
    }
    

    get error:

    proc-macro derive panicked
    message: called `Result::unwrap()` on an `Err` value: Error("expected literal")
    

    this looks like a broken implementation of the oso::PolarClass derive macro.

    Here is demo

    opened by Siceberg 0
  • `is_allowed` succeeds even when given a resource that was never registered

    `is_allowed` succeeds even when given a resource that was never registered

    I’m using the Rust Oso client and found that I can use is_allowed() with objects of PolarClasses that have not been registered. Here’s an example: https://github.com/davepacheco/oso-issue-classes/blob/bc0d4b02f1be608096055a2b9f32b25c43f9ca86/src/main.rs (particularly L47-48 highlights the problem)

    I’d expect this to return an error because I wasn't sure why it would ever make sense to ask about an instance of a class that doesn't even exist. @patrickod in Slack explained that this permissiveness might be intended for dynamic languages where it may be a parent class that's been registered. Maybe this can be made stricter for Rust or else under some option?

    Why this matters to us: in short, it's surprisingly easy in our system to forget to do the registration and when that happens it's really hard to figure out why the authz check has failed. More context: we've got a few dozen Polar classes. Many of them behave identically. We auto-generate both Rust types and the Polar snippets for them. (This might be kind of fishy?) When a developer adds a new type, they need to (1) invoke the macro, and (2) remember to add it to a list of types to be registered. If they forget, their authz checks simply fail, rather than producing an error. This is really hard to debug because the Rust type is correct (but not registered), the Polar snippet is correct (but not passed into Oso), and Oso produces no error -- just an unexpected answer.

    opened by davepacheco 1
  • sqlalchemy-oso cannot handle or clauses involving joins

    sqlalchemy-oso cannot handle or clauses involving joins

    Environment

    oso 0.26.1 sqlalchemy-oso 0.26.1 Python 3.10

    Setup

    Given these models:

    class User(db.Model):
      id = Column(BigInteger, primary_key=True)
    
    class Group(db.Model):
      id = Column(BigInteger, primary_key=True)
      type = Column(String)
      members = relationship("User", secondary="Membership", viewonly=True)
    
    class Membership(db.Model):
      user_id=Column(ForeignKey(User.id), primary_key=True)
      group_id=Column(ForeignKey(Group.id), primary_key=True)
    

    And a policy like:

    has_role(user: User, "member", group: Group) if user in group.members;
    allow(user: User, "read", group: Group) if group.type = "PUBLIC" or has_role(user, "member", group);
    

    Problem

    For a query like:

    Group.query.all()
    

    The generated query is incorrectly using an inner join instead of a left join:

    SELECT ...
    FROM group, membership AS membership_1
    WHERE group.type = %s OR group.id = membership_1.group_id AND %s = membership_1.user_id
    

    This results in the query skipping public groups that the user is not a member of.

    Partial workaround

    I have rewritten my model to work around this partially (poor scalability) by changing the policy to look like:

    has_role(user: User, "member", group: Group) if group.id in user.get_group_ids();
    

    and adding the following method to the User model:

    def get_group_ids(self):
            return [i.group_id for i in Member.query.filter_b(user_id=self.id)]
    

    This results in a query like:

    SELECT ...
    FROM group
    WHERE group.type = %s OR group.id = %s OR group.id = %s ...
    

    This works, but has scalability issues if the group list is too large.

    opened by snstanton 1
Releases(sqlalchemy-v0.26.2)
Owner
Oso
Putting security into the hands of developers
Oso
Example of a simple application which is powered by a third-party oAuth 2.0 server for it's authentication / authorization. Written in Golang.

go mod init github.com/bartmika/osin-thirdparty-example go get github.com/spf13/cobra go get github.com/openshift/osin go get github.com/openshift/osi

Bartlomiej Mika 0 Jan 4, 2022
Mini-framework for multiple authentication and authorization schemes

Go authorization pattern This repository demonstrates an authorization pattern that allows multiple schemes. Demo To start the demo run the following

Tim van Osch 0 Dec 30, 2021
An authorization library that supports access control models like ACL, RBAC, ABAC in Golang

Casbin News: still worry about how to write the correct Casbin policy? Casbin online editor is coming to help! Try it at: https://casbin.org/editor/ C

Casbin 12.5k Aug 4, 2022
⛩️ Go library for protecting HTTP handlers with authorization bearer token.

G8, pronounced Gate, is a simple Go library for protecting HTTP handlers with tokens. Tired of constantly re-implementing a security layer for each

Chris C. 41 Jul 31, 2022
An authorization library that supports access control models like ACL, RBAC, ABAC in Golang

Casbin News: still worry about how to write the correct Casbin policy? Casbin online editor is coming to help! Try it at: https://casbin.org/editor/ C

Casbin 12.5k Aug 5, 2022
Go library providing in-memory implementation of an OAuth2 Authorization Server / OpenID Provider

dispans Go library providing in-memory implementation of an OAuth2 Authorization Server / OpenID Provider. The name comes from the Swedish word dispen

Xenit AB 3 Dec 22, 2021
ACL, RBAC, ABAC authorization middleware for KubeSphere

casbin-kubesphere-auth Casbin-kubesphere-auth is a plugin which apply several security authentication check on kubesphere via casbin. This plugin supp

Casbin 4 Jun 9, 2022
an stateless OpenID Connect authorization server that mints ID Tokens from Webauthn challenges

Webauthn-oidc Webauthn-oidc is a very minimal OIDC authorization server that only supports webauthn for authentication. This can be used to bootstrap

Arian van Putten 13 May 16, 2022
policy - the CLI for managing authorization policies

policy - the CLI for managing authorization policies The policy CLI is a tool for building, versioning and publishing your authorization policies. It

Open Policy Registry 87 Aug 3, 2022
Authorization As A Service

a3s NOTE: this is a work in progress and this software is not usable yet a3s (stands for Auth As A Service) is an authentication and ABAC authorizatio

Palo Alto Networks 4 Feb 11, 2022
telegram authorization in telegram without using a widget

TGAH - telegram Authorization Example of authorization in telegram without using a widget Installation go get -d github.com/tioffs/[email protected] Setti

tioffs 2 Jun 6, 2022
A demo of authentication and authorization using jwt

Nogopy Hi, this a demo of how to use jwt for authentication in microservices Keep in mind that this is a demo of how to authenticate using jwt, we don

null 2 Nov 1, 2021
Backend Development Rest Api Project for book management system. Used Features like redis, jwt token,validation and authorization.

Golang-restapi-project Simple Rest Api Project with Authentication, Autherization,Validation and Connection with redis File Structure ├── cache │ ├──

Srijan Chakraborty 1 May 25, 2022
A library for Go client applications that need to perform OAuth authorization against a server

oauth-0.8.0.zip oauth A library for Go client applications that need to perform OAuth authorization against a server, typically GitHub.com. Traditiona

tigressma 1 Oct 13, 2021
Authelia: an open-source authentication and authorization server providing two-factor authentication

Authelia is an open-source authentication and authorization server providing two

Streato 0 Jan 5, 2022
🔑 Authz0 is an automated authorization test tool. Unauthorized access can be identified based on URL and Role.

Authz0 is an automated authorization test tool. Unauthorized access can be identified based on URL and Role. URLs and Roles are managed as YAML-based

HAHWUL 288 Jul 16, 2022
Goauth: Pre-made OAuth/OpenIDConnect and general authorization hooks for webapp login

goauth Pre-made OAuth/OpenIDConnect and general authorization hooks for webapp login. Currently supports Google, Facebook and Microsoft "out of the bo

Steven Frew 0 Jan 28, 2022
Go-auth - An authorization project using mongoDB, JWT and Go

Ssibrahimbas Go-Auth An authorization project using mongoDB, JWT and Go. API Typ

Sami Salih İbrahimbaş 1 Mar 10, 2022
Scaffold to help building Terraform Providers using AWS IAM authentication.

Terraform Provider Scaffolding This repository is a template for a Terraform provider. It is intended as a starting point for creating Terraform provi

Paul Zietsman 1 Mar 31, 2022