When reading about REST APIs and security, you invariably see OAuth 2.0 as the authentication panacea. But actually diving into the specs, true OAuth 2.0 requires service and authentication providers be separate, primarily so the authentication provider can be used for multiple services. Also clients are untrusted and not given credentials. OAuth seems an overly convoluted if your service and auth provider are the same.
On top of that many APIs just use some sort of client id/client secret into bearer token flow. Which is no better than username/password into session.
You split between Auth[-Provider] and Service-Provider, but actually there are 3 pieces involved:
Authentication.
Service Provider.
Service Consumer.
It is very common that Authentication and Service Provider are done by the same party.
It depends on the service consumer, if you need OAuth or not. In case you want 3-rd party applications to consume your services ON BEHALF of your users, OAuth is very useful.
Related
I know that you can define scopes for Google OAuth2, but can you define scopes for Google SAML?
I have read Google SAML docs and also some standard information about Google SAML, but wasn't able to get any info on it.
Short answer: No.
SAML is a different protocol where an identity provider grants access to a service. Since the SAML protocol only supports identity information it doesn't support OAuth 2.0 scopes, but SAML applications can request additional scopes through a regular consent screen after the user accesses the service.
Actually, OAuth is an authorization process where is mainly OAuth 2.0 is designed as an authorization protocol permitting a user to share access to specific resources with a service provider.
OAuth handles authorization, and SAML handles authentication.
On the other hand, SAML is typically used for SSO in government and enterprise applications (identity management) which does not require scopes because it is an authentication process.
Regardless, OAuth2 does not support SSO. And SAML tends to be specific to a user, while OAuth tends to be specific to an application.
Moreover, Google Cloud platform has the option to use OpenID connect where Google's OAuth 2.0 APIs can be used for both authentication and authorization.
I have several REST APIs which I want to secure with a federated authorization server. This page: https://oauth.net/articles/authentication/ suggests that OAuth2 alone is not enough for authentication and one should use the OpenId Connect extension to get it right.
However, I have the feeling that what OIDC does is only defining an identity endpoint and the related scopes and claims. If I don't specifically need these identity claims, what's wrong with using plain OAuth authorization code for authenticating a user and protecting resource? Or is OAuth2 only for delegating access to a client app which works on behalf of the user (which is not my use cas)?
Thanks for the inputs!
Most end user authentication related work occurs on the UI side of things, and of course involves Authorization Redirects, Identity Providers, Consent Forms and so on.
In terms of the code for a Secured REST API you instead perform the following types of action. This is primarily OAuth 2.0 behaviour as you say, though Open Id Connect endpoints can be useful:
Validate received access tokens from the Authorization Server
Read token claims to identify the authenticated user
To do this you may need to download token signing keys from the JWKS endpoint
Your API can look up further details from the User Info endpoint
Your API can use the metadata endpoint to get the above endpoint locations
Your API will then apply authorization rules based on claims and scopes
OAuth is an authorization framework. Before OpenID Connect, some organizations were increasingly using OAuth as an authentication mechanism just as you stated in your question. While this is technically possible, it is rife with inconsistencies between one implementation to the next. The standardization of this method came around with OpenID Connect, where this group of vendors essentially said let's come up with a standardized approach to what we have been doing. The benefits of a standardized approach is collaboration, security, etc. The openid scope of OAuth was born.
I have an internal app that allows users to sign in using Azure AD. On authentication, a SAML assertion is returned. However, some of the calls that the application makes require a JWT. WHat is the best way for me to get a JWT when a user signs in? Or is there a way for me to exchange the SAML for a JWT?
Disclaimer: I'm not expert an any of this stuff; I'm still learning it too and struggling with a similar problem. That said, here is my understanding.
I'm pretty sure there is no connection between SAML and JWT. Not a surprise, given that SAML 2.0 dates back to 2005 and JWT got started around 2012. So it's logically impossible for the SAML spec to say anything about JWTs.
If my understanding is correct, you have two options:
Do not use SAML directly. Instead of interacting with a SAML IdP (identity provider), use OpenID Connect and OAuth 2.0 with a provider that acts as an authentication broker. Configure the broker to act as service provider to your chosen SAML IdP. Configure your application to act as relying party (OAuth terminology, I think?) on the authentication broker. Then your app is OAuth 2.0/OpenID Connect/JWT all the way down. Your only interaction with SAML is configuring an authentication broker. Main downside is now you have to select and pay for an authentication broker as well as a SAML IdP.
Write your own authentication/authorization service to consume SAML assertions and issue JWTs. This might be necessary anyways, depending on how you need to represent authorization info in your JWTs.
We have a Mulesoft Cloudhub environment which we are planning to deploy public APIs and we also have a VPC configured where we will deploy private APIs.
I'm looking at how best to secure the APIs and seen the following approaches:
Basic Authentication
Client Id and secret
OAuth
LDAP
SAML
My query is when should you use each one? Are their example use cases? E.g. OAuth seems to be more secure than basic authentication and client id and secret so why not use OAuth all the time and forget about the other two?
Thanks
OAuth is geared more towards authorisation rather than just authentication.
For example OAuth 2 has many different flows geared towards different use-cases. Such as 3 legged OAuth allowing you to use an external identity provider allow users to be authorised to access your resources. In a way, you’re not performing any authentication at all.
Http basic can still have a purpose in simple scenarios MAYBE when the cost and/or effort of using something else is not worth it and it’s internal network and the OJ already have some sort of ldap or active directory type thing is use for other apps (and using SSL is very important here as basic auth credentials are plain text)
For client id and secret, although it is similar to username/password, it’s more in the semantics - you are trusting a client rather than a person with the credentials.
For example, you can use client id to authenticate actual clients like a mobile application or a web app. Client id implementation like MuleSoft’s API Manager also allow you to add policies such as rate limiting and SLA based rate limiting so you can limit specific client applications to not overload your API.
You could use it alongside OAuth. Client ID/Secret for accessing the API but OAuth for authorising the end-user .
Here is a more detailed article discussing the pros and cons of the various common api auth mechanisms and a link to choosing between the various OAuth flows for your use-case.
https://nordicapis.com/3-common-methods-api-authentication-explained/
https://auth0.com/docs/api-auth/which-oauth-flow-to-use
We are building a web application in microservices architecture.
We have a service that handles the authorization (i.e user's privileges, access credentials, roles etc...) and we are considering how to pass on these credentials in the system.
We have 2 option:
1. Sign those credentials in the gateway (auth and proxy service) using JWT and pass on all the information so every service could verify it (with its public key) and read the user's info.
2. Every service should make a request to the authorization service for querying the user's access on every action.
We are having difficulties on deciding which way is better in terms of high cohesion and loose coupling and of course making it easy for service development.
You have some other options: instead of reinventing the wheel, you can use an OAuth 2.0 identity provider/broker out of the box.
Keycloak is a free open source identity provider and broker that provides all these functionalities.
Auth0 is a managed commercial service that provides all these functionalities too.
And I'm sure there are many other services exist for OAuth 2.0 protocol.
As for your 2 options:
You can extend the JWT with your custom authorisation claims (roles or permissions) and since the JWT will be signed, then it is safe to assume the data is correct by your service. Give that the JWT is a short lived token that need to renew every few minutes.