Skip to content

AuthN + AuthZ solution for internal apps #36

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 2 commits into
base: master
Choose a base branch
from
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
12 changes: 12 additions & 0 deletions recommendations/details/customer_facing_auth.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,12 @@
# Customer Auth for public-facing website and App

## Current State
- The Moda website currently uses a combination of [Devise](https://github.com/plataformatec/devise) and [Doorkeeper](https://github.com/doorkeeper-gem/doorkeeper) to provide authentication and tokens to customers.
- There are some limited authorization functionality such as private trunkshows.

## Migrating to Identity as a Service (such as Auth0)
- Decrease internal security threat profile
- Anomaly-detection and Bot protection utilities
- Potentially enhance authorization features to customers. For example, VIP customers could be given access to view/purchase items not on the site, private trunkshows, etc.
- Authorization can be done in a session-less manner.
- It will cost more
34 changes: 34 additions & 0 deletions recommendations/details/internal_auth.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,34 @@
# Authentication and authorization for internal users and applications
- Pink, Pumo and Stylist Suite currently uses a combination of [Devise](https://github.com/plataformatec/devise) and [Doorkeeper](https://github.com/doorkeeper-gem/doorkeeper) to provide authentication and tokens to admin users.
- Users are assigned roles that are composed of fine-grained permissions
- Validating a user request against their permissions requires a DB request
- Very little separation between users and customers
- Currently not using scopes for access control
- Missing OIDC features like audiences, JWT and UserInfo endpoint (could be enabled through Doorkeeper extensions)

# AWS Elastic Load Balance and API Gateway
- support vanilla OIDC providers
- simpler since microservice endpoints only need to think about tokens and not the entire auth flow

# GSuite as an identity provider
- All employees are GSuite users
- Easy to provision/ deprovision
- Difficult to assign roles and persist them in JWT
- What about third parties that are not in Gsuite?

# JSON Web Tokens
- cryptographically signed
- decentralized
- can be inspected (in a web browser, for example)

# Identity as a Service
## Auth0
- Used by Vendor Portal
- Supports enterprise integrations (GSuite)
- security certifications
- Audit trail
- Many more things
## Cognito
- Supports any OIDC identity provider
- Provided Auth primitives as opposed to a polished Auth product