I wrote a sample ballerina code in choreo API to return x-jwt-header header value to the caller.
when I turn off the security for that API, the header value is not there in the request headers. Does it mean the API is unsecured?
I want to crate an unsecured API. I want to know whether the header values will be there or not?
When you disable the security, basically API is exposed without security to the consumers. Hence the API is unsecured. x-jwt-header is used to pass the enduser data to the backend services. If you don't provide an access token when invoking API, then it can't send the enduser information to the backend services. That's why you are getting the response without that header.
Related
We have a .NET microservice based app where the Gateway is built using Ocelot. Until now we didn't do any authentication in the Gateway, the frontend calls an Authentication Provider service which responds with an JWT token, the token gets added to request headers and then, the new requests go through gateway and each particular microservice is concerned with authentication and authorization.
We also have API Key based authentication in place, but it's not used until now.
I added a new microservice with authentication done by API Key and I want to handle authorization in the Gateway. That means the gateway should check the claims based on JWT token and if claims matches forward the request to the microservice using an API key header.
How can I do it with Ocelot, instead of writing controllers and actions for each corresponding microservice controllers and actions? I thought about implementing Delegating Handlers to take care of it, but maybe there is a better way?
A clean way to do this, is to have the access token between the client and the API gateway and to then use the token exchange flow between the gateway and the underlying APIs so as to keep a potential attack surface on the initial access token small and avoid exposing internal mechanics (e.g. multiple audiences of underlying APIs in your initial access token, multiple api scopes).
There are many sources of information about this online. Here's one to get you started.
I'm interested in using Azure APIMS to authenticate requests from a client app using Azure AD. However, I am interested in having the backend API know details about the user who was authenticated at the gateway such that I can perform logic based on that user.
Backend API would be ASP.NET Core 3.x web api.
What approaches are available to me?
One thing I can think of off the top of my head is to simply forward the Authentication header along to the backend API, and do some type of lookup there. But I am wondering if there is any way for me to aggregate the user details at the frontend api gateway layer, and pass that information along in a header?
How are backend applications obtaining details about the authenticated user when requests are authenticated at the frontend gateway layer?
I realize that if I was to add authentication at the backend API layer (which would duplicate the authentication/authorization) I may be able to technically accomplish it this way. However, this would violate the SRP principle and perhaps add some necessary overhead to the backend.
Azure AD authentication at APIM would mostly imply validating JWT token passed along with request. You can callout to other endpoints if you want to with send-request policy to obtain more information (for example, do group expansion), but that would have to be explicitly configured through policies.
After token is validated it's available to you in object model form so you can inspect its properties and use any part of the token in policy expressions, say to send parts of it as headers to your backend API.
I have a Lambda function which triggered by API Gateway service, however this API is accessed by front-end application, this application not requiring the users to login or sign up to use it.
However I would like to secure my API to allow only from my front-end application.
After my research I found that I can use custom authorization in API Gateway, this custom authorization will check the authorization header of the incoming request and validate it.
the question is, can I use Amazon Cognito for something like this(implicit grant type)?
if not what is the thing that the front-end application will send to me to be validated and how can I keep it always changeable, so no one can guess it?
Thank You.
You could check the headers, but if they're always the same, someone can send an HTTP request with those headers - from any client - and trick your Lambda into thinking it's coming from your UI.
Even if you generate a unique token every time your UI is loaded and include it in the headers, someone could take that token and send requests from another client as well.
You could build fancy JavaScript tricks to make headers more dynamic, but it would only make it harder to use your API from another client, not impossible.
I'm planning an API and I haven't found any information about where the access token should be placed in the response. I'm interested in the case where I'm providing the access token. What is the best practice to send the token to the clients (from the backend service)?
Should it be sent to clients in the Header or in the Body of the answer?
You should look at examples and see what others do. For example, Facebook, Twitter, Google, Amazon... and all those popular PaaS services exposing a REST API all use OAuth2 as authentication mechanism:
In OAuth2 you'll see the specification requires to send the generated token to the client in the body of a json response: https://www.rfc-editor.org/rfc/rfc6749#section-5 . But you can also see how Google and other vendors extend this mechanism so it can be sent as a callback url param, for example (Check out https://developers.google.com/identity/protocols/OAuth2UserAgent).
Once you get the authorization token you put it on the Authorization: HTTP header you send on your requests for accessing protected resources. They have to support this way of doing it, because it is how the OAuth2 standard specifies it https://www.rfc-editor.org/rfc/rfc6749#section-7
If you want to tinker a little bit more with oauth, check out https://developers.google.com/oauthplayground
(OAuth is pretty much the same thing.)
They usually also extend the Authorization header mechanism to allow the token to be provided as a GET/POST parameter in the url or the body of the response, respectively (For example, Facebook's Graph API also supports passing an access_token= parameter on your HTTP POST request body or GET URI). There is no way to manipulate or even read HTTP headers on a javascript browser application (see the modern fetch API and other proposals on Accessing the web page's HTTP Headers in JavaScript), so providing this functionality makes life easier for many app developers.
Another popular authentication scheme is SOAP authentication. It doesn't support tokens but it supports digest authentication, which is a similar thing. The interesting part of it is that it is not HTTP/Web based (although it is primarily used that way), so you can use it over other application protocols. It's a little more cumbersome, but you can find ready to use implementations for both server and client.
You can also use digest authentication over HTTP without SOAP. It is also based on Authorization: headers and every browser supports it. Check out https://en.wikipedia.org/wiki/Digest_access_authentication to see how the authorization headers are formed in different ways depending on the level of security you want to reach.
Some services, like redmine, allow you to use an API token (API key) instead of a session token. Then you can make basic http auth on your requests like https://whatever:yourapikey#example.com/protectedMethod, although passing of auth data on URLs is currently deprecated in favor of basic auth header, and plain passwords / static API keys should only be sent over secured SSL connections. In this case the client can have the server generate an api key using a web interface or a rest api (so the generated key will be passed as a JSON response). This method may not be such a good idea, though: Check http://talks.codegram.com/http-authentication-methods#/intro if you want to know why, and also this question discussing where to put them: Where should I place API keys in REST API calls?
I have been reading about OAuth and it keeps talking about endpoints. What is exactly an endpoint?
Come on guys :) We could do it simpler, by examples:
/this-is-an-endpoint
/another/endpoint
/some/other/endpoint
/login
/accounts
/cart/items
and when put under a domain, it would look like:
https://example.com/this-is-an-endpoint
https://example.com/another/endpoint
https://example.com/some/other/endpoint
https://example.com/login
https://example.com/accounts
https://example.com/cart/items
Can be either http or https, we use https in the example.
Also endpoint can be different for different HTTP methods, for example:
GET /item/{id}
PUT /item/{id}
would be two different endpoints - one for retrieving (as in "cRud" abbreviation), and the other for updating (as in "crUd")
And that's all, really that simple!
All of the answers posted so far are correct, an endpoint is simply one end of a communication channel. In the case of OAuth, there are three endpoints you need to be concerned with:
Temporary Credential Request URI (called the Request Token URL in the OAuth 1.0a community spec). This is a URI that you send a request to in order to obtain an unauthorized Request Token from the server / service provider.
Resource Owner Authorization URI (called the User Authorization URL in the OAuth 1.0a community spec). This is a URI that you direct the user to to authorize a Request Token obtained from the Temporary Credential Request URI.
Token Request URI (called the Access Token URL in the OAuth 1.0a community spec). This is a URI that you send a request to in order to exchange an authorized Request Token for an Access Token which can then be used to obtain access to a Protected Resource.
It's one end of a communication channel, so often this would be represented as the URL of a server or service.
An endpoint is a URL pattern used to communicate with an API.
An endpoint is the 'connection point' of a service, tool, or application accessed over a network. In the world of software, any software application that is running and "listening" for connections uses an endpoint as the "front door." When you want to connect to the application/service/tool to exchange data you connect to its endpoint
Endpoint, in the OpenID authentication lingo, is the URL to which you send (POST) the authentication request.
Excerpts from Google authentication API
To get the Google OpenID endpoint, perform discovery by sending either a GET or HEAD HTTP request to https://www.google.com/accounts/o8/id. When using a GET, we recommend setting the Accept header to "application/xrds+xml". Google returns an XRDS document containing an OpenID provider endpoint URL.The endpoint address is annotated as:
<Service priority="0">
<Type>http://specs.openid.net/auth/2.0/server</Type>
<URI>{Google's login endpoint URI}</URI>
</Service>
Once you've acquired the Google endpoint, you can send authentication requests to it, specifying the appropriate parameters (available at the linked page). You connect to the endpoint by sending a request to the URL or by making an HTTP POST request.
Short answer: "an endpoint is an abstraction that models the end of a message channel through which a system can send or receive messages" (Ibsen, 2010).
Endpoint vs URI (disambiguation)
The endpoint is not the same as a URI. One reason is because a URI can drive to different endpoints like an endpoint to GET, another to POST, and so on. Example:
#GET /api/agents/{agent_id} //Returns data from the agent identified by *agent_id*
#PUT /api/agents/{agent_id} //Update data of the agent identified by *agent_id*
Endpoint vs resource (disambiguation)
The endpoint is not the same as a resource. One reason is because different endpoints can drive to the same resource. Example:
#GET /api/agents/{agent_id} #Produces("application/xml") //Returns data in XML format
#GET /api/agents/{agent_id} #Produces("application/json") //Returns data in JSON format
The term Endpoint was initially used for WCF services. Later even though this word is being used synonymous to API resources, REST recommends to call these URI (URI[s] which understand HTTP verbs and follow REST architecture) as "Resource".
In a nutshell, a Resource or Endpoint is kind of an entry point to a remotely hosted application which lets the users to communicate to it via HTTP protocol.
The endpoint of the term is the URL that is focused on creating a request.
Take a look at the following examples from different points:
/api/groups/6/workings/1
/api/v2/groups/5/workings/2
/api/workings/3
They can clearly access the same source in a given API.
API stands for Application Programming Interface. It is a way for your application to interact with other applications via an endpoint. Conversely, you can build out an API for your application that is available for other developers to utilize/connect to via HTTP methods, which are RESTful. Representational State Transfer (REST):
GET: Retrieve data from an API endpoint.
PUT: Update data via an API - similar to POST but more about updating info.
POST: Send data to an API.
DELETE: Remove data from given API.
PATCH: Update data.