How can I set up authentication and authorization layers with Gun.js the tradicional way, for example with social logins with (Google, LinkedIn) or AWS cognito, Auth0,our my own RBAC server?
Centralized login systems give access tokens to a server and session tokens to the user.
Unfortunately, this means you cannot do fully p2p logins if you want to support other logins, because the server that receives the access token will need to have a "backdoor" into GUN's cryptographic user accounts.
If users are okay with this backdoor...
Then, save their keypair (or generate a secret password) privately to their profile on your existing centralized user account system. Now you can automatically log them into GUN by calling gun.user().auth(keypair).
Related
What are the main differences between Authentication and Authorization? Please explain this in a simple way.
Authentication vs. Authorization
So, what is the difference between authentication and authorization? Simply put, authentication is the process of verifying who someone is, whereas authorization is the process of verifying what specific applications, files, and data a user has access to.
What Is Authentication?
Authentication is the act of validating that users are whom they claim to be. This is the first step in any security process.
Authentication process with;
Passwords. Usernames and passwords are the most common authentication
factors. If a user enters the correct data, the system assumes the
identity is valid and grants access.
One-time pins. Grant access for only one session or transaction.
Authentication apps. Generate security codes via an outside party
that grants access.
Biometrics. A user presents a fingerprint or eye scan to gain access
to the system.
What Is Authorization?
Authorization in system security is the process of giving the user permission to access a specific resource or function. This term is often used interchangeably with access control or client privilege.
Giving someone permission to download a particular file on a server or providing individual users with administrative access to an application are good examples of authorization.
In secure environments, authorization must always follow authentication. Users should first prove that their identities are genuine before an organization’s administrators grant them access to the requested resources.
Authentication vs. Authorization
I want to design my private cloud with multiple services to make my live eassier. For better usability, I want to be able to login with the same credentials. For that I looked at ldap and openID especially openldap and freeipa. But with FIDO2 coming up and making loggin in way eassier and safer, I wonder if there is a way to use FIDO2 in combination with ldap or openID so users can login with their FIDO2 tokens while having the same credentials for all services.
So in federated authentication there are three parties. Federated Client(The website about Cats), Federated Provider(your mega identity provider) and Authentication Service(the thing that authenticates).
In terms of OIDC, the OIDC Server will redirect to the auth service with a challenge. The auth service will then fetch request info via private(admin) api from the OIDC service, and it then will perform all necessary check, authenticate user and then ask if user wants to allow KittyCats.xyz to use user account to authenticate. If user agrees, the Auth Server will then notify the OIDC Server hat user gave consent, and in response the OIDC server will return redirect_url. The AuthServer will then redirect user to the specified redirect URL.
So in terms of FIDO this is quiet simple. You make a basic FIDO authentication service, then add OIDC logic on top of it and voila, you have FIDO backed OIDC federated authentication.
If you want to play around I highly suggest playing around with ORY/HYDRA. They have a full demo with a mini Auth Service and a wonderful tutorial to get you started: https://www.ory.sh/hydra/docs/5min-tutorial
according to here (https://oauth.net/articles/authentication/) and many other things I have come across. OAuth is not meant to handle end user authentication. Reading through the article above and others while searching provides so much information at once from so many angles that it is hard to see through it all. ok...
Does this mean that...
A) The protocol itself is not intended to handle authentication, so therefore, OAuth client apps should inspect "who" can authorize users according to the OAuth providers?
If ONLY the user can authorize third party apps, then isn't the fact of receiving authorization from the OAuth provider in itself proof of authentication? (if this is the case, then can OAuth access tokens from places like Google and Facebook be trusted as authentications?)
B) OAuth client apps cannot trust authenticating users with OAuth, so therefore must provide another sound authentication mechanism alongside it?
If this is the case, then every site that I have clicked "Login With [provider]" (and no other complementary authentication scheme) has got authentication wrong?
It seems to me that if only trusted and specific OAuth providers are used, then this flow could infer authentication
App requests login with trusted providers
User is directed to provider to authorize (ONLY user can authorize)
App then requests and receives token from provider, and adds user to the app database if necessary.
Token is put into secure cookie or JWT and returned to the user to be presented on subsequent visits.
The purpose of OAuth2 access token is to delegate some access rights (scopes) from a user to a client application. So the application redirects the user to an authentication provider (OAuth2 server), which authenticates the user and asks the user (consent step) whether he/she wants to delegate some access rights (the scopes requested by the application) to the application.
If a client application receives an access token, it can get its meta data at the OAuth2 introspection endpoint - such as username of the user (resource owner). So this way, the OAuth2 can be used for authentication. But the main purpose of access tokens is to delegate some rights. For example if a third party application wants to save its data to a user's Google Drive, it needs an access token issued by Google with scopes that allow it to access Google Drive.
If you want to use OAuth2 only for authentication in your client application (to get identity of a user), you can use OpenId Connect (OAuth2 extension) and its ID token, which is in JWT format and contains information about the user that was authenticated the authentication provider. This is better suited for the "Login With ..." functionality.
I've been reading about OAuth and OpenID Connect extensively, but this question is specifically about the OAuth2 Resource Owner Password Grant (aka OAuth2 Resource owner credentials Grant, aka OAuth2 Password Grant)
Some resources (like the book "OAuth2 in Action" by Justin Richer) says not to use OAuth2 Resource Owner Password Grant for authentication - see section 6.1.3 in the book.
Other good resources like the following all say we can use the OAuth2 Resource Owner Password Grant to essentially authenticate users via trusted apps:
https://www.oauth.com/oauth2-servers/access-tokens/password-grant/
https://stormpath.com/blog/the-ultimate-guide-to-mobile-api-security
https://www.youtube.com/watch?v=FNz0Lupp8HM&index=60&list=PLyUlngzGzkztgTizxM6_zqiw8sRj7vBm0
https://docs.apigee.com/api-services/content/implementing-password-grant-type
https://oauth2.thephpleague.com/authorization-server/which-grant/
https://aaronparecki.com/oauth-2-simplified/#others
But I'm having a hard time understanding why we shouldn't use the OAuth2 Resource Owner Password Grant as essentially proof of a successful authentication?
My understanding of Resource Owner Password Grant flow is that a username and password is provided by the end user to the trusted client (my native app), which then forwards it to my API's OAuth server and exchanges it for an access token (and optional refresh token) that it can use for the rest of the authenticated API endpoints. The native app doesn't save the username/password, but instead relies on the short-lived access token and the longer-lived refresh token (to get fresh access tokens when they expire).
Why would I even need OpenID Connect? Why can't I just use OAuth2 Resource Owner Password Grant as an authentication mechanism?
Both the native app and the API are developed by the same person (me).
Any explanations would be welcome. Thank you.
If both the server and the client application are yours, you may use Resource Owner Password Credentials flow to get access tokens.
If the server is yours but client applications are not yours (= if client applications are developed by third-party vendors), your server should not allow client applications to use Resource Owner Password Credentials flow. It's because Resource Owner Password Credentials flow cannot prevent third-party client applications from stealing end-users' passwords.
The specification of OpenID Connect does not describe how an OpenID provider should authenticate end-users. Instead, the specification describes how an OpenID provider should generate ID tokens. Because an ID token contains a signature generated by the OpenID provider, client applications that receive the ID token can verify that the ID token has been really signed by the OpenID provider.
That is, OpenID Connect is a specification as to how to make the result of end-user authentication be verifiable. It's not a specification as to how to authenticate end-users.
The resource owner credentials grant is of the higher risk then any other grants and defeats the purpose of the protocol, which aims to hide user credentials from the client application.
In the case of native app - you are right, its possible to analyze your app and retrieve the consumer key from it. Also I can imagine someone creates an app similar to yours, and fishes user's password out of it, and executes other potentially malicious actions without users noticing.
I suggest you read the specifications of OAuth2 and OpenID Connect.
Why should you NOT use the resource owner password grant (from OAuth2 spec):
The resource owner password credentials grant type is often used for
legacy or migration reasons. It reduces the overall risk of storing
usernames and passwords by the client but does not eliminate the need
to expose highly privileged credentials to the client.
This grant type carries a higher risk than other grant types because
it maintains the password anti-pattern this protocol seeks to avoid.
The client could abuse the password, or the password could
unintentionally be disclosed to an attacker (e.g., via log files or
other records kept by the client).
Additionally, because the resource owner does not have control over
the authorization process (the resource owner's involvement ends when
it hands over its credentials to the client), the client can obtain
access tokens with a broader scope than desired by the resource
owner. The authorization server should consider the scope and
lifetime of access tokens issued via this grant type.
The authorization server and client SHOULD minimize use of this grant
type and utilize other grant types whenever possible.
OAuth 2.0, regardless of the grant type, is not an authentication protocol.
OpenID Connect is an Authentication Protocol built on top of OAuth 2.0
These are some references (Several are from folks that wrote the OAuth 2.0 and/or OpenID Connect):
http://www.thread-safe.com/2012/01/problem-with-oauth-for-authentication.html
https://twitter.com/ve7jtb/status/740650395735871488
https://nat.sakimura.org/2013/07/05/identity-authentication-oauth-openid-connect/
http://ldapwiki.com/wiki/OAuth%202.0%20NOT%20an%20Authentication%20protocol
I have an app with confidential PII (social security number, payroll information). I'd like to enable users to login with OAuth IDs (Google, Linked In) for convenience but require those accounts have multi-factor authentication enabled in the identity provider, i.e. fail the login through OAuth2 if the user hasn't enabled MFA in their underlying identity provider account. This allows me to avoid exposing my confidential information to a weak GMail password.
Is there any way to do this?
Unfortunately, no.
In the case of Google and Linkedin, the authentication level is not linked to a specific scope. The Oauth response doesn't specify either if the user used an OTP token or not..
Even if the user is enrolled in MFA, the user can register the computer he's using as a trusted one and in this case, Google will never prompt him for an OTP. This behaviour may prevent many users to access your application.
Actually, I believe you could check on your own session / token to see if it was done through Google, Twitter, Facebook, etc and then require MFA / 2FA / OTP on the first use of that token. Does that make sense?
You could run your own TOTP microservice using Browser Authenticator which has the components you need to generate and verify a key and token in the browser and Node Authenticator which has the complementary server-side code.
Just add your own storage mechanism and an https call to microservice, update the session / token, and viola, you've added two-factor / multi-factor / one-time password authentication right on top of them.