Giter Club home page Giter Club logo

ory / hydra Goto Github PK

View Code? Open in Web Editor NEW
15.0K 231.0 1.4K 115.9 MB

OpenID Certified™ OpenID Connect and OAuth Provider written in Go - cloud native, security-first, open source API security for your infrastructure. SDKs for any language. Works with Hardware Security Modules. Compatible with MITREid.

Home Page: https://www.ory.sh/hydra/?utm_source=github&utm_medium=banner&utm_campaign=hydra

License: Apache License 2.0

Go 85.85% Shell 2.05% Dockerfile 0.15% Makefile 0.42% JavaScript 5.31% Ruby 6.22%
hydra oauth2 openid-connect docker server security authorization identity federation cloud

hydra's Introduction

Ory Hydra - Open Source OAuth 2 and OpenID Connect server


CI Tasks for Ory Hydra Go Report Card PkgGoDev CII Best Practices

Ory Hydra is a hardened, OpenID Certified OAuth 2.0 Server and OpenID Connect Provider optimized for low-latency, high throughput, and low resource consumption. Ory Hydra is not an identity provider (user sign up, user login, password reset flow), but connects to your existing identity provider through a login and consent app. Implementing the login and consent app in a different language is easy, and exemplary consent apps (Node) and SDKs for common languages are provided.

Ory Hydra can use Ory Kratos as its identity server.

Ory Hydra on the Ory Network

The Ory Network is the fastest, most secure and worry-free way to use Ory's Services. Ory OAuth2 & OpenID Connect is powered by the Ory Hydra open source federation server, and it's fully API-compatible.

The Ory Network provides the infrastructure for modern end-to-end security:

  • Identity & credential management scaling to billions of users and devices
  • Registration, Login and Account management flows for passkey, biometric, social, SSO and multi-factor authentication
  • Pre-built login, registration and account management pages and components
  • OAuth2 and OpenID provider for single sign on, API access and machine-to-machine authorization
  • Low-latency permission checks based on Google's Zanzibar model and with built-in support for the Ory Permission Language

It's fully managed, highly available, developer & compliance-friendly!

  • GDPR-friendly secure storage with data locality
  • Cloud-native APIs, compatible with Ory's Open Source servers
  • Comprehensive admin tools with the web-based Ory Console and the Ory Command Line Interface (CLI)
  • Extensive documentation, straightforward examples and easy-to-follow guides
  • Fair, usage-based pricing

Sign up for a free developer account today!

Ory Network Hybrid Support Plan

Ory offers a support plan for Ory Network Hybrid, including Ory on private cloud deployments. If you have a self-hosted solution and would like help, consider a support plan! The team at Ory has years of experience in cloud computing. Ory's offering is the only official program for qualified support from the maintainers. For more information see the website or book a meeting!

Get Started

You can use Docker to run Ory Hydra locally or use the Ory CLI to try out Ory Hydra:

# This example works best in Bash
bash <(curl https://raw.githubusercontent.com/ory/meta/master/install.sh) -b . ory
sudo mv ./ory /usr/local/bin/

# Or with Homebrew installed
brew install ory/tap/cli

create a new project (you may also use Docker)

ory create project --name "Ory Hydra 2.0 Example"
project_id="{set to the id from output}"

and follow the quick & easy steps below.

OAuth 2.0 Client Credentials / Machine-to-Machine

Create an OAuth 2.0 Client, and run the OAuth 2.0 Client Credentials flow:

ory create oauth2-client --project $project_id \
    --name "Client Credentials Demo" \
    --grant-type client_credentials
client_id="{set to client id from output}"
client_secret="{set to client secret from output}"

ory perform client-credentials --client-id=$client_id --client-secret=$client_secret --project $project_id
access_token="{set to access token from output}"

ory introspect token $access_token --project $project_id

OAuth 2.0 Authorize Code + OpenID Connect

Try out the OAuth 2.0 Authorize Code grant right away!

By accepting permissions openid and offline_access at the consent screen, Ory refreshes and OpenID Connect ID token,

ory create oauth2-client --project $project_id \
    --name "Authorize Code with OpenID Connect Demo" \
    --grant-type authorization_code,refresh_token \
    --response-type code \
    --redirect-uri http://127.0.0.1:4446/callback
code_client_id="{set to client id from output}"
code_client_secret="{set to client secret from output}"

ory perform authorization-code \
    --project $project_id \
    --client-id $code_client_id \
    --client-secret $code_client_secret
code_access_token="{set to access token from output}"

ory introspect token $code_access_token --project $project_id

What is Ory Hydra?

Ory Hydra is a server implementation of the OAuth 2.0 authorization framework and the OpenID Connect Core 1.0. Existing OAuth2 implementations usually ship as libraries or SDKs such as node-oauth2-server or Ory Fosite, or as fully featured identity solutions with user management and user interfaces, such as Keycloak.

Implementing and using OAuth2 without understanding the whole specification is challenging and prone to errors, even when SDKs are being used. The primary goal of Ory Hydra is to make OAuth 2.0 and OpenID Connect 1.0 better accessible.

Ory Hydra implements the flows described in OAuth2 and OpenID Connect 1.0 without forcing you to use a "Hydra User Management" or some template engine or a predefined front-end. Instead, it relies on HTTP redirection and cryptographic methods to verify user consent allowing you to use Ory Hydra with any authentication endpoint, be it Ory Kratos, authboss, User Frosting or your proprietary Java authentication.

Who's using it?

The Ory community stands on the shoulders of individuals, companies, and maintainers. The Ory team thanks everyone involved - from submitting bug reports and feature requests, to contributing patches and documentation. The Ory community counts more than 33.000 members and is growing rapidly. The Ory stack protects 60.000.000.000+ API requests every month with over 400.000+ active service nodes. None of this would have been possible without each and everyone of you!

The following list represents companies that have accompanied us along the way and that have made outstanding contributions to our ecosystem. If you think that your company deserves a spot here, reach out to [email protected] now!

Type Name Logo Website
Adopter * Raspberry PI Foundation Raspberry PI Foundation raspberrypi.org
Adopter * Kyma Project Kyma Project kyma-project.io
Adopter * Tulip Tulip Retail tulip.com
Adopter * Cashdeck / All My Funds All My Funds cashdeck.com.au
Adopter * Hootsuite Hootsuite hootsuite.com
Adopter * Segment Segment segment.com
Adopter * Arduino Arduino arduino.cc
Adopter * DataDetect Datadetect unifiedglobalarchiving.com/data-detect/
Adopter * Sainsbury's Sainsbury's sainsburys.co.uk
Adopter * Contraste Contraste contraste.com
Adopter * Reyah Reyah reyah.eu
Adopter * Zero Project Zero by Commit getzero.dev
Adopter * Padis Padis padis.io
Adopter * Cloudbear Cloudbear cloudbear.eu
Adopter * Security Onion Solutions Security Onion Solutions securityonionsolutions.com
Adopter * Factly Factly factlylabs.com
Adopter * Nortal Nortal nortal.com
Adopter * OrderMyGear OrderMyGear ordermygear.com
Adopter * Spiri.bo Spiri.bo spiri.bo
Adopter * Strivacity Spiri.bo strivacity.com
Adopter * Hanko Hanko hanko.io
Adopter * Rabbit Rabbit rabbit.co.th
Adopter * inMusic InMusic inmusicbrands.com
Adopter * Buhta Buhta buhta.com
Adopter * Connctd Connctd connctd.com
Adopter * Paralus Paralus paralus.io
Adopter * TIER IV TIER IV tier4.jp
Adopter * R2Devops R2Devops r2devops.io
Adopter * LunaSec LunaSec lunasec.io
Adopter * Serlo Serlo serlo.org
Adopter * dyrector.io dyrector.io dyrector.io
Adopter * Stackspin stackspin.net stackspin.net
Adopter * Amplitude amplitude.com amplitude.com
Adopter * Pinniped pinniped.dev pinniped.dev
Adopter * Pvotal pvotal.tech pvotal.tech

Many thanks to all individual contributors

* Uses one of Ory's major projects in production.

OAuth2 and OpenID Connect: Open Standards!

Ory Hydra implements Open Standards set by the IETF:

and the OpenID Foundation:

OpenID Connect Certified

Ory Hydra is an OpenID Foundation certified OpenID Provider (OP).

Ory Hydra is a certified OpenID Providier

The following OpenID profiles are certified:

To obtain certification, we deployed the reference user login and consent app (unmodified) and Ory Hydra v1.0.0.

Quickstart

This section is a starter guide to working with Ory Hydra. In-depth docs are available as well:

  • The documentation is available here.
  • The REST API documentation is available here.

Installation

Head over to the Ory Developer Documentation to learn how to install Ory Hydra on Linux, macOS, Windows, and Docker and how to build Ory Hydra from source.

Ecosystem

We build Ory on several guiding principles when it comes to our architecture design:

  • Minimal dependencies
  • Runs everywhere
  • Scales without effort
  • Minimize room for human and network errors

Ory's architecture is designed to run best on a Container Orchestration system such as Kubernetes, CloudFoundry, OpenShift, and similar projects. Binaries are small (5-15MB) and available for all popular processor types (ARM, AMD64, i386) and operating systems (FreeBSD, Linux, macOS, Windows) without system dependencies (Java, Node, Ruby, libxml, ...).

Ory Kratos: Identity and User Infrastructure and Management

Ory Kratos is an API-first Identity and User Management system that is built according to cloud architecture best practices. It implements core use cases that almost every software application needs to deal with: Self-service Login and Registration, Multi-Factor Authentication (MFA/2FA), Account Recovery and Verification, Profile, and Account Management.

Ory Hydra: OAuth2 & OpenID Connect Server

Ory Hydra is an OpenID Certified™ OAuth2 and OpenID Connect Provider which easily connects to any existing identity system by writing a tiny "bridge" application. It gives absolute control over the user interface and user experience flows.

Ory Oathkeeper: Identity & Access Proxy

Ory Oathkeeper is a BeyondCorp/Zero Trust Identity & Access Proxy (IAP) with configurable authentication, authorization, and request mutation rules for your web services: Authenticate JWT, Access Tokens, API Keys, mTLS; Check if the contained subject is allowed to perform the request; Encode resulting content into custom headers (X-User-ID), JSON Web Tokens and more!

Ory Keto: Access Control Policies as a Server

Ory Keto is a policy decision point. It uses a set of access control policies, similar to AWS IAM Policies, in order to determine whether a subject (user, application, service, car, ...) is authorized to perform a certain action on a resource.

Security

Why should I use Ory Hydra? It's not that hard to implement two OAuth2 endpoints and there are numerous SDKs out there!

OAuth2 and OAuth2 related specifications are over 400 written pages. Implementing OAuth2 is easy, getting it right is hard. Ory Hydra is trusted by companies all around the world, has a vibrant community and faces millions of requests in production each day. Of course, we also compiled a security guide with more details on cryptography and security concepts. Read the security guide now.

Disclosing vulnerabilities

If you think you found a security vulnerability, please refrain from posting it publicly on the forums, the chat, or GitHub. You can find all info for responsible disclosure in our security.txt.

Benchmarks

Our continuous integration runs a collection of benchmarks against Ory Hydra. You can find the results here.

Telemetry

Our services collect summarized, anonymized data that can optionally be turned off. Click here to learn more.

Documentation

Guide

The full Ory Hydra documentation is available here.

HTTP API documentation

The HTTP API is documented here.

Upgrading and Changelog

New releases might introduce breaking changes. To help you identify and incorporate those changes, we document these changes in CHANGELOG.md.

Command line documentation

Run hydra -h or hydra help.

Develop

We love all contributions! Please read our contribution guidelines.

Dependencies

You need Go 1.13+ with GO111MODULE=on and (for the test suites):

  • Docker and Docker Compose
  • Makefile
  • NodeJS / npm

It is possible to develop Ory Hydra on Windows, but please be aware that all guides assume a Unix shell like bash or zsh.

Formatting Code

You can format all code using make format. Our CI checks if your code is properly formatted.

Running Tests

There are three types of tests you can run:

  • Short tests (do not require a SQL database like PostgreSQL)
  • Regular tests (do require PostgreSQL, MySQL, CockroachDB)
  • End to end tests (do require databases and will use a test browser)

All of the above tests can be run using the makefile. See the commands below.

Makefile commands

# quick tests
make quicktest

# regular tests
make test
test-resetdb

# end-to-end tests
make e2e
Short Tests

It is recommended to use the make file to run your tests using make quicktest , however, you can still use the go test command.

Please note:

All tests run against a sqlite in-memory database, thus it is required to use the -tags sqlite,json1 build tag.

Short tests run fairly quickly. You can either test all of the code at once:

go test -v -failfast -short -tags sqlite,json1 ./...

or test just a specific module:

go test -v -failfast -short -tags sqlite,json1 ./client

or a specific test:

go test -v -failfast -short -tags sqlite,json1 -run ^TestName$ ./...
Regular Tests

Regular tests require a database set up. Our test suite is able to work with docker directly (using ory/dockertest) but we encourage to use the Makefile instead. Using dockertest can bloat the number of Docker Images on your system and are quite slow. Instead we recommend doing:

make test

Please be aware that make test recreates the databases every time you run make test. This can be annoying if you are trying to fix something very specific and need the database tests all the time. In that case we suggest that you initialize the databases with:

make test-resetdb
export TEST_DATABASE_MYSQL='mysql://root:secret@(127.0.0.1:3444)/mysql?parseTime=true&multiStatements=true'
export TEST_DATABASE_POSTGRESQL='postgres://postgres:[email protected]:3445/postgres?sslmode=disable'
export TEST_DATABASE_COCKROACHDB='cockroach://[email protected]:3446/defaultdb?sslmode=disable'

Then you can run go test as often as you'd like:

go test -p 1 ./...

# or in a module:
cd client; go test .

E2E Tests

The E2E tests use Cypress to run full browser tests. You can execute these tests with:

make e2e

The runner will not show the Browser window, as it runs in the CI Mode (background). That makes debugging these type of tests very difficult, but thankfully you can run the e2e test in the browser which helps with debugging! Just run:

./test/e2e/circle-ci.bash memory --watch

# Or for the JSON Web Token Access Token strategy:
# ./test/e2e/circle-ci.bash memory-jwt --watch

or if you would like to test one of the databases:

make test-resetdb
export TEST_DATABASE_MYSQL='mysql://root:secret@(127.0.0.1:3444)/mysql?parseTime=true&multiStatements=true'
export TEST_DATABASE_POSTGRESQL='postgres://postgres:[email protected]:3445/postgres?sslmode=disable'
export TEST_DATABASE_COCKROACHDB='cockroach://[email protected]:3446/defaultdb?sslmode=disable'

# You can test against each individual database:
./test/e2e/circle-ci.bash postgres --watch
./test/e2e/circle-ci.bash memory --watch
./test/e2e/circle-ci.bash mysql --watch
# ...

Once you run the script, a Cypress window will appear. Hit the button "Run all Specs"!

The code for these tests is located in ./cypress/integration and ./cypress/support and ./cypress/helpers. The website you're seeing is located in ./test/e2e/oauth2-client.

OpenID Connect Conformity Tests

To run Ory Hydra against the OpenID Connect conformity suite, run

$ test/conformity/start.sh --build

and then in a separate shell

$ test/conformity/test.sh

Running these tests will take a significant amount of time which is why they are not part of the CI pipeline.

Build Docker

You can build a development Docker Image using:

make docker

Run the Docker Compose quickstarts

If you wish to check your code changes against any of the docker-compose quickstart files, run:

make docker
docker compose -f quickstart.yml up # ....

Add a new migration

  1. mkdir persistence/sql/src/YYYYMMDD000001_migration_name/
  2. Put the migration files into this directory, following the standard naming conventions. If you wish to execute different parts of a migration in separate transactions, add split marks (lines with the text --split) where desired. Why this might be necessary is explained in gobuffalo/fizz#104.
  3. Run make persistence/sql/migrations/<migration_id> to generate migration fragments.
  4. If an update causes the migration to have fewer fragments than the number already generated, run make persistence/sql/migrations/<migration_id>-clean. This is equivalent to a rm command with the right parameters, but comes with better tab completion.
  5. Before committing generated migration fragments, run the above clean command and generate a fresh copy of migration fragments to make sure the sql/src and sql/migrations directories are consistent.

Libraries and third-party projects

Official:

Community:

Developer Blog:

  • Visit the Ory Blog for guides, tutorials and articles around Ory Hydra and the Ory ecosystem.

hydra's People

Contributors

aarmam avatar aaslamin avatar abusaidm avatar aeneasr avatar alnr avatar arekkas avatar cherrymu avatar demonsthere avatar dennispattmann5012 avatar dependabot[bot] avatar euank avatar grantzvolsky avatar hperl avatar icyphox avatar jayme-github avatar kevgo avatar kminehart avatar lopezator avatar matheusfm avatar mdrollette avatar mfzl avatar mitar avatar ory-bot avatar pbarker avatar sawadashota avatar sgal avatar someone1 avatar svrakitin avatar vinckr avatar zepatrik avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

hydra's Issues

Implement default identity provider using postgres

This will be part of #62

I want hydra to be able to maintain a list of identity providers which can be added and removed using the CLI:

hydra idp add https://identities.foobar.com/
hydra idp remove https://identities.foobar.com/

Hydra should ship a default/exemplary identity provider using postgres located here. Identity providers must implement an HTTP REST interface with (at least) the following capabilities:

Mandatory (used by Hydra):

  • GET /identities: Should return all known identities. Should support pagination.
  • GET /identities/<id>: Should return an identities information
  • POST /authenticate: Should return an identitiy if valid credentials are given. Question: What to support id/password, username/password, email/password, ... ?

Recommended: Not used by Hydra but useful in a real world scenario:

  • POST /identities: Should create a new user
  • DELETE /identities/<id>: Should delete a user
  • PUT /identities/<id>/password: Should update the identities password

Optional features:

  • Password reset
  • ... ?

Identities should be sent using JSON:

{
    "id": "12341234" // mandatory
    // ...
}

Errors should be sent using the HTTP status header and a JSON message:

{
    "error": "Not found",
    "description": "some reason"
}

For inspiration check out the current account module

Too many open files probably caused by http client

lrwx------ 1 vagrant vagrant 64 Jan  5 15:00 10 -> socket:[18251]
lrwx------ 1 vagrant vagrant 64 Jan  5 15:30 100 -> socket:[20067]
lrwx------ 1 vagrant vagrant 64 Jan  5 19:21 1000 -> socket:[33658]
lrwx------ 1 vagrant vagrant 64 Jan  5 19:21 1001 -> socket:[33661]
lrwx------ 1 vagrant vagrant 64 Jan  5 19:21 1002 -> socket:[33664]
lrwx------ 1 vagrant vagrant 64 Jan  5 19:21 1003 -> socket:[33675]
lrwx------ 1 vagrant vagrant 64 Jan  5 19:21 1004 -> socket:[33678]
lrwx------ 1 vagrant vagrant 64 Jan  5 19:21 1005 -> socket:[33681]
lrwx------ 1 vagrant vagrant 64 Jan  5 19:21 1006 -> socket:[33684]
lrwx------ 1 vagrant vagrant 64 Jan  5 19:21 1007 -> socket:[33687]
lrwx------ 1 vagrant vagrant 64 Jan  5 19:21 1008 -> socket:[33691]
lrwx------ 1 vagrant vagrant 64 Jan  5 19:21 1009 -> socket:[33699]
lrwx------ 1 vagrant vagrant 64 Jan  5 15:30 101 -> socket:[20070]
lrwx------ 1 vagrant vagrant 64 Jan  5 19:21 1010 -> socket:[33702]
lrwx------ 1 vagrant vagrant 64 Jan  5 19:21 1011 -> socket:[33705]
lrwx------ 1 vagrant vagrant 64 Jan  5 19:21 1012 -> socket:[33708]
.....

Check resources:

Creating clients with predefined credentials

It would be a nice feature to pass ID/secret pair to hydra clients create.

This is only for development of course. Right now I have to parse .hydra.yml to get the trusted client's credentials. It would be much easier to just have them predefined and hard-coded somewhere.

Add support for scopes

Hydra does not offer any scope related capabilities right now. We might add OpenID Connector as a scope in the future but apart from that no further implementation has been planned.

It would however be very simple to add support for scopes as scopes could simply be forwarded to the sign in provider.

Continue using JWT as access tokens?

JWTs as access token are great, because we can retrieve important information like subject or issuer by simply decoding the access token without "tough" crypto methods. Additionally, we can verify that the access token is valid by checking the signature against Hydra's public key.

JWTs as access tokens are bad, because they bloat every request by about 8-9 times. Dropbox uses access tokens with 64 characters, JWTs tend to be around 550 characters.

Please feel free to state your opinions on this matter here. A viable option could be to provide different strategies and select one through an environment variable.

Remove dockertest dependency from handlers

848d6db introduces mocks for client and middleware. Use them in handler tests and remove dockertest dependency in these. This should significantly increase testing performance and improve error / exception handling.

support for ldap for user storage

I don't know how to handle that in a nice and microservice way (have hydra to connect to 3rd-party user provider, that all must fullfil a http api contract, so that any body can implement his user provider and it will connect nicely with hydra, without needing to have that in hydra itself ?)

But as this tool is aim for corporate scenario, and a lot of company do store their user in LDAP, hence being able to get the user from there would IMHO greatly the places where hydra would be relavant.

ory-am ssl cert invalid

screen shot 2016-03-10 at 11 24 00 am

which is worrying for a company writing security / auth tools...

(link taken from this github project)

docs: add passport.js real-world example

Create a passport.js example app and include it in docker compose


Using react for the exemplary identity provider is nice and all, but react is hard to understand for people who do not use react a lot. Instead, a minimalistic nodejs application should be used.

support SAML in addition to OAuth2

In addition to OAuth2, the SAML protocol would be great to have, to support legacy application that doesn't speak OAuth2 (and god knows there's a lot in corporate world)

spoiler: in my company (of several hundreds employees) OAuth2/SAML and LDAP/MySQL are the two things we're using for authentication, and having these would cover nearly all our use cases

Granted Endpoint Proposal: Performant access decisions for resource providers using REST

Right now, there is no endpoint for resource providers. They rely on the guard and introspect endpoint. I propose to merge the guard and introspect in a new and powerful endpoint called Granted (available at /oauth2/granted). This endpoint requires:

Header

  • Authorize: basic with a client id and secret. The client must exist and be explicitly allowed to access the lookup endpoint.

POST JSON Body

  • token: {token}: The access token to be inspected
  • resource: {resource-name}: The resource that is being accessed
  • permission: {permission}: The permission that is being required
  • context: A object for decisions based on conditions.
    • resourceOwner: {owner-id}: The resource's owner
    • requestIP: {request-ip-address}: The IP address which issued the request
    • requestedAt: {ISO-8601-date}: The time the request was issued
    • requestUserAgent: {request-user-agent}: The user agent that issued the request
    • ... this list could be expandable

Non-normative example:

{
    "token": "jklsdfopiqw34-ltspgodyxoz.jfkal1jk8g09",
    "resource": "rn:some:resource:name",
    "permission": "delete",
    "context": {
        "resourceOwner": "peter",
        "resourceIP": "127.0.0.1",
    }
}

Response JSON

  • granted: {true|false}: If access was granted to the token
  • error: {message}: Error explains why the grant request was denied. Only set if access was denied.

Errors

  • This endpoint returns 401 unauthorized if the client credentials are invalid
  • This endpoint returns 403 forbidden if the client is forbidden from using this endpoint.

This prevents third parties from using this endpoint. Third parties should use the introspect endpoint instead, because it checks if token audience and client id match, which is not required for resource providers!

Are there standards for connecting to third party providers

Right now, Hydra allows to connect to different providers by supplying a provider param to the authorize url: hydra/oauth2/auth?provider=dropbox&cliend_id=123&...

At this point in time, only Dropbox and Login are shipped but this is going to change with #33 . The Login provider acts as a fallback and basically redirects the user to a url and expects that endpoint to redirect the user back to hydra, providing a "login token" (you might already see the unintentional similarity to OpenID Connector) which the Login provider then validates and exchanges for an authorize code.

I have seen a similar approach at Auth0.com but I would really like to find a spec for this and implement it instead of shipping my own solution.

So here's the question: Is there a standard way to specify a (thirdparty) ID provider like Dropbox, Google or some other IdP? I would appreciate any help :)

Security "audit" pre-analysis (based on rfc6749)

Hydra is in an early stage. There are multiple potential security issues that have not yet been considered or have been implemented wrongly. This is a list of (potential) issues, that need resolving before using Hydra in a production environment.

  • rfc6749/AuthCode: If the client can be authenticated, the authorization servers MUST authenticate the client and ensure that the authorization code was issued to the same client.
  • rfc6749/AuthCode: Authorization codes MUST be short lived and single-use. If the authorization server observes multiple attempts to exchange an authorization code for an access token, the authorization server SHOULD attempt to revoke all access tokens already granted based on the compromised authorization code.
  • rfc6749/RefreshToken: Refresh tokens MUST be kept confidential in transit and storage, and
    shared only among the authorization server and the client to whom the
    refresh tokens were issued. The authorization server MUST maintain
    the binding between a refresh token and the client to whom it was
    issued.
  • rfc6749/RedirectURI: ... the authorization server MUST
    ensure that the redirection URI used to obtain the authorization code
    is identical to the redirection URI provided when exchanging the
    authorization code for an access token. The authorization server
    MUST require public clients and SHOULD require confidential clients
    to register their redirection URIs. If a redirection URI is provided
    in the request, the authorization server MUST validate it against the
    registered value.
  • rfc6749/ResourceOwnerPasswordCredentials: The authorization server and client SHOULD minimize use of this grant type and utilize other grant types whenever possible. This has to be fixed here
  • rfc6749/GuessingAttacks: The probability of an attacker guessing generated tokens (and other
    credentials not intended for handling by end-users) MUST be less than
    or equal to 2^(-128) and SHOULD be less than or equal to 2^(-160).
  • rfc6749/CSRF: The authorization server MUST implement CSRF protection for its
    authorization endpoint and ensure that a malicious client cannot
    obtain authorization without the awareness and explicit consent of
    the resource owner. Please revalidate front-end workflows.
  • rfc6749/ClickJacking: To prevent this form of attack, native applications SHOULD use
    external browsers instead of embedding browsers within the
    application when requesting end-user authorization. Make this an explicit note in the README
  • rfc6749/ImplicitImpersonation: Any public client that makes the assumption that only the resource
    owner can present it with a valid access token for the resource is
    vulnerable to this type of attack.
    This type of attack may expose information about the resource owner
    at the legitimate client to the attacker (malicious client). This
    will also allow the attacker to perform operations at the legitimate
    client with the same permissions as the resource owner who originally
    granted the access token or authorization code.
    Authenticating resource owners to clients is out of scope for this
    specification. Any specification that uses the authorization process
    as a form of delegated end-user authentication to the client (e.g.,
    third-party sign-in service) MUST NOT use the implicit flow without
    additional security mechanisms that would enable the client to
    determine if the access token was issued for its use (e.g., audience-
    restricting the access token). This is should be avoidable by implementing OIDC and informing client developers

Please be aware that not all of the items above affect Hydra. This is just a list of things that have to be reviewed.

CLI refactor and initial account set up

Instead of being able to run administrative commands directly from hydra-host, I want to have an hydra-cli that uses the HTTP REST interface provided hydra-host to manage that stuff. hydra would always require a hydra login command followed by client or user credentials (a valid OAuth2 Token should be issued).

The initial administrative account credentials would be created as followed:

  • A one time password (OTP) is generated by hydra when a fresh installation is detected.
  • The OTP is printed to STDOUT
  • The operator (the user who is installing hydra) runs hydra account create or hydra client create and will be prompted to provide the OTP. If a valid OTP is provided, the operator will be asked for an id and a password and must give confirmation that the account/client to be created is being granted super rights which allow him to do anything anytime anywhere.

Update GoRethink imports

Hey, I was having a quick look through the latest release (congratulations by the way) and noticed that you were importing GoRethink using two different imports (github.com/dancannon/gorethink and gopkg.in/dancannon/gorethink.v2).

It would probably make sense to only use one of them, preferably gopkg.in/dancannon/gorethink.v2.

2fa: add two factor authentication helper API

We could introduce a simple TOTP API endpoint for creating and validating TOTPs.

package twofa

import (
    "github.com/go-errors/errors"
    "github.com/pquerna/otp/totp"
)

type Manager interface {
    Generate(subject string) error
    Validate(subject string) error
}

type TOTP struct {
    Issuer string
    Period uint
}

func (m *TOTP) Generate(subject string) error {
    _, err := totp.Generate(totp.GenerateOpts{
        // Name of the issuing Organization/Company.
        Issuer: m.Issuer,
        // Name of the User's Account (eg, email address)
        AccountName: subject,
        // Number of seconds a TOTP hash is valid for. Defaults to 30 seconds.
        Period: m.Period,
    })
    if err != nil {
        return errors.New(err)
    }

    return nil
}

Security audit based on rfc6819

rfc6819 contains OAuth 2.0 Threat Model and Security Considerations.

Review thread model

  • 4.1 Clients
  • 4.2 Authorization Endpoint
  • 4.3 Token Endpoint
  • 4.4 Obtaining Authorization
  • 4.5 Refreshing an Access Token

Review security considerations

  • 5.1. General
  • 5.2. Authorization Server
  • 5.3. Client App Security
  • 5.4. Resource Servers
  • 5.5. A Word on User Interaction and User-Installed Apps

warden: add group management and group based policy checks

Subpackage to policy:

package group

type Group struct {
    ID       string   `json:"id"`
    Members  []string `json:"members"`
    Policies []string `json:"policies"`
}

type Groups map[string]*Group

type Manager interface {
    GetGroup(id string) (Group, error)

    JoinGroup(user, group string) error

    LeaveGroup(user, group string) error

    CreateGroup(group Group) error

    AddGroupPolicy(policy, group string) error

    RemoveGroupPolicy(policy, group string) error

    DeleteGroup(id string) error
}

cmd: Allow SYSTEM_SECRET key rotation

Key rotation is tricky because we either need a table lock for JWK or an overlord. Having an overlord who is attached to rethinkdb might be the smartest thing to do. There should never be more than one overlord running (how to ensure this? table row? ttl?).

The system secret key rotation definitely needs an overlord. Key exchange could done through HTTP:

  • Poll last key creation and check TTL
  • Generate new secret
  • Gather a list of all running instances
  • Authorize via access token
  • Provide old secret
  • Provide new secret

Alternatively the new secret could be encrypted with the old key and stored in the database. Everyone who has the old key, can read the new one as well. This would save the trouble of instance discovery as all instances are connected to rethinkdb anyways.

Using policies and IP ranges, access to the endpoint could be allowed to trusted addresses only.

On system key rotation, all JWKs must be re-encrypted using the new key. All tokens become invalid when the key changes which is why sysem key ttl must be larger than token ttl. This way we can be sure that all instances can validate tokens using either the old or the new key

go install fails

Hi,
I just tried to install hydra and go install fails with:

$ go install github.com/ory-am/hydra
# github.com/ory-am/hydra/internal
../go/src/github.com/ory-am/hydra/internal/fosite_store_memory.go:27: undefined: fosite.ErrNotFound
../go/src/github.com/ory-am/hydra/internal/fosite_store_memory.go:45: undefined: fosite.ErrNotFound
../go/src/github.com/ory-am/hydra/internal/fosite_store_memory.go:63: undefined: fosite.ErrNotFound
../go/src/github.com/ory-am/hydra/internal/fosite_store_memory.go:81: undefined: fosite.ErrNotFound
../go/src/github.com/ory-am/hydra/internal/fosite_store_rethinkdb.go:116: undefined: fosite.ErrNotFound
../go/src/github.com/ory-am/hydra/internal/fosite_store_rethinkdb.go:132: undefined: fosite.ErrNotFound
../go/src/github.com/ory-am/hydra/internal/fosite_store_rethinkdb.go:149: undefined: fosite.ErrNotFound
../go/src/github.com/ory-am/hydra/internal/fosite_store_rethinkdb.go:166: undefined: fosite.ErrNotFound

Thanks

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.