Accepting a bearer token from another REST API - rest

I have a rest API (Parent) where a user requests a bearer token with username/password. This API can make a call to another API (Child) but I'd like the Parent's bearer token to server as authorization for Child access. I guess similar to how SSO works but for web services. How can this be done in .net core?

Related

How to use cognito id token as authorization header for API gateway?

I have an API http gateway (at say https://example.com) integrated with an API REST gateway which uses a Cognito authorizer. All of this to serve a single-page React application. The behaviour is as expected:
I launch the Cognito hosted UI and sign in,
It redirects to the url https://example.com/#id_token=123
If I use PostMan, I can access that url if I pass that id_token in the Authorization header.
Now my question is: how can I pass the header automatically after signing in so I can visit https://example.com?
I have spent a long time on this and have found many similar posts without an answer:
How to use the code returned from Cognito to get AWS credentials?
How can I link cognito token and API authentication header automatically?
AWS Cognito hosted UI returning id_token in URL
How can I make the redirect_uri of AWS Cognito (Hosted UI) authenticated?
Set Authorization header when redirecting client from Cognito to AWS API Gateway
How do I handle a Cognito auth redirect for a Lambda / API Gateway for UI?
We faced the same question a couple of years ago. Our solution was creating a proxy (using API Gateway and Lambda) that "moved" the id_token (stored in a cookie) to the Authorization header for every request to the server. It was ugly, but it worked.
BTW, getting id_token in the URL is how Implicit Grant works. But Implicit Grant is generally considered less secure than Authorization Code Grant. We have since migrated from Implicit Grant to Authorization Code Grant. However, we continue to use the proxy pattern (again using API Gateway and Lambda) as follows.
Exchange the returned code for access_token and id_token at the Cognito user pool's token endpoint. Store the tokens in a DynamoDB table with session_cookie as the partition key. Return the session_cookie as a cookie (with HttpOnly, Secure and SameSite=Strict) to the browser.
For each request from the browser, use the cookie to find the token in the DynamoDB table and put the token in the Authorization header.

how do I return a Bearer Token supplied by my server

I'm using Vapor to handle http requests. I've implemented a registration and login, as well as other functioning code. On registration, a Bearer Token is generated, so I can return that to or write it into the page I'm about to render.
The page contains two forms, one of which generates a request that requires authorization, so I need to associate that request with the bearer token. How do I do this? Through explicitly setting headers for the form request that will be sent to the server? Via a cookie?
If you're writing a traditional web app using HTML then bearer authentication is not suitable as you can't attach custom headers with requests. You should use session based authentication as described in the docs

Approah on creating clients/realms for separate service (frontend and backend)

I'm new to keycloak and would like to check what is the common design on the said architecture.
I have 1 backend(quarkus) 1 frontend (angular) and 1 flutter.
I would like to see if I could leverage the features of client. My idea is to have a separate client within the realm. For example
REALM = MyAppRealm
Client = backend-client and front-endclient
Is it possible that the token i got from front-endclient can be use to access the api from the backend?
Reason I have this setup is that the front-endclient has a public accesstype while the backend has confidential
to sum up. I would like to see if i can reuse the token i got from front-endclient to my backend-client
Yes of course you can do that.
The purpose of openid is to share authentication and authorization between a diversity of clients without needing to share credentials (no password is known by any of the clients). A trusted third party (here Keycloak) will give back a signed token in exchange for credentials. And this token will be a proof of who the user is and what he is allowed to do in the communications between the frontend and backend.
To sum up :
Your angular frontend authenticates an user using a public client and an implicit flow. When successfully authenticated, the frontend obtains an access token and a refresh token.
When making a REST call to the backend, your frontend needs to set the header Authorization using the access token as a bearer token ('Authorization: Bearer insert access token here'). You can automate this by using an interceptor (example)
Finally, when your backend receive an API request it can check the Authorization header to ensure the request is authenticated and authorized. For how to do that with Quarkus, everything is explained in this documentation page : https://quarkus.io/guides/security-openid-connect

What is the advantage of a custom API in Auth0?

Question
I got a problem with understanding some basic thing about auth0, probably someone can help me out.
In the tutorial SPA + API one of the first lines in the TDLR is this:
Both the SPA and the API must be configured in the Auth0 Dashboard
I dont understand why I need to configure the API on Auth0. My code seems to work so can anyone help me understand if I do something wrong or what the advantages are if I actually add a custom API in my dashboard?
Setup
SPA (React)
Auth0
REST API (ktor)
What I do
Created a SPA on Auth0
Login on my SPA through Auth0 to get a JWT (google token)
Sending the JWT as authentication bearer in my calls to the REST API
REST API verifies the JWT token with a JWK provider using the Auth0 url mydomain.eu.auth0.com/.well-known/jwks.json.
Authentication seems to work
Great question, I am assuming that your authentication request includes audience parameter which represents your custom API(Rest API)right now. In oauth2 terms, it is called Resource Server. Each resource server can have many permissions which you include in the scope when initiating the authentication request. Let's step back and talk about the token format. Auth0 issues token in two formats:
Opaque strings: When not using a custom API
JSON Web Tokens (JWTs): When using a custom API
https://auth0.com/docs/tokens/reference/access-token/access-token-formats#how-does-all-this-affect-the-token-format-
As explained above link, the token format depends on the audience (Custom API) parameter. Therefore, when the authentication request includes audience, auth0 issues JWT token with all necessary permission. Then, you need to validate the JWT token in your API server before returning the resources to your front end client.
It should make sense why you need to create custom API in auth0 and define permissions. If you do not create custom API in auth0, there is no way to know what kind of permission you need in the token which will generate an error(invalid audience specified)

two level authentication test

the app we have has two levels of authentication. First it authorizes user with a Basic token. This authentication generates bearer token (session specific). The user can use this bearer token to various transactions in the app.
Flows:
user authentication at auth.xxxx.com with Basic token
user then redirected to api.xxx.com to do various transactions - uses bearer token generated from 1
I am not understanding how I could use basic / bearer session token any tools available, I have tried it in PostMan and HP's UFT.
The situation aptly described here from a developer standpoint: How to implement two level authentication in a RESTful API?
I had to capture the passKey using Json Extractor and then use RegEx extractor to get bearer token. NO programming was required