Background
I'm looking into securing a selection of APIs for a client. I'm pretty familiar with the Auth0 offering and quite confident that it will serve me well as an auth provider.
The APIs will be deployed on GCP (Google Cloud Platform) and I've been looking into using Apigee to manage the life cycle of my APIs.
Question
Does Apigee offer an auth store for users similar to what Auth0 offers or is Apigee's OAuth implementation limited to application level authentication using Consumer Key and Consumer Secret as described here?
Apigee OAuth implementation is not limited to Consumer Key/Secret (client credentials grant) but you also can implement different OAuth grant types. Apigee can generate/validate JWT and it's own opaque tokens.
The problem is that Apigee does not provide Identity Provider (IdP) service, it means that it does not have a store for user credentials. You may utilize Apigee's BaaS (Backend-as-a-Service) to store users or integrate Apigee with other IdPs, but there's no built-in solution to authenticate users.
Related
I have created a Web API using .net core 5. I have secured the app using the Microsoft Identity platform. Clients app are able to get to the resource based on their scope/role. So I know that my api is secure.
Now, I need to add the API to Azure API Management tool.
So my question is should I enable OAuth from the Azure API Management to secure my web api even though my app is already secured?. What would be the reason that I enable OAuth from API management?
APIM is a proxy to the backend APIs and implementing security mechanisms to give an extra layer of security to prevent unauthorized access to APIs is a recommended practice.
Configuring OAuth 2.0 Server in APIM merely enables the Developer Portal’s test console as APIM’s client to acquire a token from Azure Active Directory. In the real world, customer will have a different client app that will need to be configured in AAD to get a valid OAuth token that APIM can validate.
OAuth is an authorization framework which allows a recognized client to acquire an access token from an authorization server.
As given in this Microsoft Doc, the Microsoft Identity Platform uses the OAuth 2.0 protocol for handling authorization.
Please find below references makes you how OAuth secures the Web APIs/Services:
OAuth 2.0 and Azure API Management
How does OAuth secure Rest API calls
Protect APIs using OAuth 2.0 in APIM
I am designing a REST API for multi-tenant app. I want to protect the API. The multi-tenant app can be subscribed by a tenant who in turn can have multiple users using the app.
I plan to use OAuth for the same. One of the possibility is to use OAuth's Client Credential Flow - where a client Id and secret is given to each tenant who subscribes to the service.
The problem with this approach is, I cannot differentiate between different users of the tenant as everyone uses the same client Id and secret to get access token.
The other option is to use the OAuth's Authorization token flow. But in this case, I am not sure how should be the interaction as it is API (non-UI).
Further, How this kind of use case be solved with SAML?
It can't. The SAML spec. doesn't have a way to pass SAML tokens to API's.
If you need user context, you need to use the authorisation grant flow. Once authenticated, you ask for a JWT tailored for that API (scope etc.) and then send that JWT to the API.
There seems to be an inconsistency in the Slack API docs in that the OAuth flow requires a client_secret be provided as part of the exchange of the code for the OAuth token as documented at https://api.slack.com/methods/oauth.access
However the client secret then needs to be embedded into the mobile app which goes against Slack's recommendations at https://api.slack.com/docs/oauth-safety which states:
Your Client Secret should be treated delicately. It is how you securely identify your application's rights and identity when exchanging tokens with Slack. Do not distribute client secrets in email, distributed native applications, client-side javascript, or public code repositories.
Are there any best practices available in terms of how to manage this discrepancy where the client secret seems to be required for auth but at the same time should not be embedded into the mobile app?
Slack only supports the Authorisation Code Flow for OAuth2.0 but it doesn't support public clients only confidential clients. It doesn't support the PKCE flow either.
Their FAQ page suggests using the RTM API if you a re developing a mobile app:
What are some real-world scenarios for 2-legged OAuth?
Is it only applicable for mobile/desktop apps?
2-legged OAuth (aka. the Client Credentials flow in OAuth 2.0) is useful when a client wants to access certain resources without disclosing its primary client credentials to the resource API. The client would authenticate to an Authorization Server to get a derived token that it can present to the resource API to get access to the protected resources.
Getting the token and presenting it is done in a standardized and interoperable way without pestering the resource API with different authentication mechanisms. It also makes revocation of access easier because that is controlled in a centralized fashion on the Authorization Server, independent of the client's primary credentials. See also: How does 2-legged oauth work in OAuth 2.0?
It is applicable across mobile, desktop and web applications although keeping a client secret in mobile and desktop applications is arguably hard so it is most suitable in server-side environments.
A real world scenario is a batch script that fetches data from a remote API and processes it.
2 legged auth is for server to server authentication on behalf of the application with no end-users involved.
For example, your application on Google AppEngine makes a request to Datastore (Database from Google Cloud). This uses 2 legged auth with JWTs.
Instead, if your application makes a request on behalf of the end user to read the user's Google Drive files, 3 legged auth is used.
I am new to security domain, so don't know whether this question is valid to be asked here. I am currently using OpenAM for the security of my web application with J2ee agent, now I find that OpenAM can do authorization with OAUTH as well as on the basis policies defined, now both openam and oauth develops tokens for valid users, and do not share user credential with the application, so how different are the two? My second question is if my application does not support oauth like google and facebook what basic things I need to do to implement oauth into my application.
OpenAM supports OAuth based authorization if that is what your confusion is about. It also supports
1) OpenID Connect
2) SAML
Your application can use either of these to get authorization from OpenAM. Your application can also use the REST APIs for this purpose. The choice is yours.
As far as the tokens go, OAuth tokens are different from OpenAM Tokens. OAuth tokens include
1) refresh_token
2) access_token
The access_token is used for making oauth based calls. However, OpenAM tokens are basically what is there in the cookie or what you get via the REST API.
Regarding your second question, to support OAuth, you would need to use a oauth client library and enable oauth on the server side (in this case OpenAM). This client library would be dependent on the language you choose to write this application.