two level authentication test - rest

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

Related

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

Difference in types of token

I am hearing continously token name of different type. Can anybody explain me different type of token with some example.
Access token
Refresh token
Oauth Token
Bearer token
JWT token.
Please forgive me if my question is incorrect. I am highly consfused so looking for the answer.
Right, terminology can be very confusing. OAuth2 is the protocol to allow a client to get an access token to access the user's data on a resource server. The protocol is token agnostic (meaning it does not specify how the token looks). So OAuth token and access token are used interchangeably.
Often, the access token used in the protocol is a structured token in the JSON Web Token (JWT) format. It contains claims (name-value pairs) with info about the user and authentication that the resource server can use.
A bearer token is any token that can be used as the sole way of authenticating. If you have the token, you get access as the user for which it was issued. Nothing else required. OAuth2 typically uses bearer tokens, although some holder-of-key tokens (where you need to prove you acquired the token by signing something) are being added to the protocol. JWT tokens are usually bearer tokens.
Refresh tokens are used in some OAuth2 protocol flows to allow the client to get a new access token when the issued one expires without asking the user to log in again. They are typically just an identifier to some row in the data store of the authorization server.

Github API authentication with OAuth (and MFA)

I am working with a Github Enterprise server. I am using Postman in an attempt to hit the API. No matter what I've tried, I get a "Sign in via LDAP" HTML page returned with a 200 status code. Not exactly what I was hoping for.
Important background:
MFA is enabled
OAuth token is a personal access token with all the scopes
I have attempted passing in the token as a URL parameter:
https://api.github.mycompany.com/repos/MyOrg/myrepo?access_token=MY_OAUTH_TOKEN
I have attempted passing in the token as an Authorization header 3 different ways:
Authorization: MY_OAUTH_TOKEN
Authorization: token MY_OAUTH_TOKEN
Authorization: Bearer MY_OAUTH_TOKEN
From what I glean from the docs, my OAuth token should be sufficient, meaning that I don't need to send any sort of MFA code. Am I wrong? What do I need to do to get real results, rather than the LDAP login page?

How to secure restful webservice with oauth?

I know that this question has been asked thousand times before but I am still unable to comprehend the answers properly. When I googled about this topic I found most of the people suggesting to use Oauth to secure Restful webservice.
I believe oauth is only applicable when you want third party applications to allow access to secured resources without sharing credentials of the user.
In my case I want to secure restful service which can only be accessed by our own developed mobile application. I am unable to understand that only for this purpose how I can utilize oauth to secure restful resources. My requirement is that for the first time user will enter his credentials into the application. Upon successful authentication application will receive a access token which then will be used to access secured resources.
Whereas in case of ouath user first of all gets redirected to the authorization provider website from mobile application (assuming mobile application as third party app) where he enters the credentials and then through a call back url the mobile application receives access token to gain access to secured resources.
I read Web API Design guide from Apigee in which they strongly recommends to use ouath. In fact Apigee App Services are secured using oauth and they are doing the same things which I need using oauth. As following curl command shows how to get access token using username and password as per apigee API Documentation.
curl -X POST -i -H "Content-Type: application/json" "https://api.usergrid.com/my-org/my-app/token" -d '{"grant_type":"password","username":"john.doe","password":"testpw"}'
My first question is that if I follow the same approach that allows third party application to get access token without any redirection and callback, will it result in violation of Oauth specification or not?
My second question is that can we use ouath for scenarios in which no third party application is involved and secured resource access is between application user and resource provider without any kind of confirmation.
This is definitely possible with OAuth2. With OAuth1 it was a bit more clumsy as you had to use '2-legged auth', which didn't feel all that natural, but in OAuth2 you can use one of these grants:
Authorization code grant
Resource Owner Password Credentials Grant

Basic Authentication with a Guid token for REST api instead of username/password

Overview
I am developing a mobile application using PhoneGap with REST API for the backend. The REST API won't be utilised by third-party developers, but will be application-specific, so there is no need for oAuth to be implemented. Hence, I am planning to use Basic Authentication where in the User enters their Username/password to access the API resources. All API communication will be on SSL.
Basic Authentication with Token
Instead of letting the application store the username/password and send it with every request to the API, I would rather authenticate username/password on the first login request and send a GUID token back. The client stores this GUID token and sends the token back to the API with each request through the Authorization header, like this:
Authorization: Basic e1d9753f-a508-46cc-a428-1787595d63e4
On the server side, the username/GUID combination will be stored on the server with a expiration date along with device settings. This will allow to keep track of the number of devices a user has logged in from as well as expire the session once the Guid has reached expiration.
Does this approach sound reasonable and secure?
There is no need for you to create custom headers or authentication schemes at all.
The Bearer authentication scheme is designed exactly for your use case:
Authorization: Bearer e1d9753f-a508-46cc-a428-1787595d63e4
Basic authentication must be as follows:
Authorization: Basic base64EncodedUsernameAndPassword
where base64EncodedUsernameAndPassword is equal to the output of:
base_64_encode(username + ':' + raw_password)
Do not use Basic if the trailing text value is not the above exact algorithm.
If you just want to put whatever value you want after the scheme name, use the Bearer scheme - that is what it was invented for.
Warning
While you can use a simple GUID/UUID as your token, this isn't really a secure token. Consider using a JWT instead. JWTs can be digitally signed and assigned a TTL so that only the server setting it can a) create it and validate its authenticity and b) ensure it is not used longer than is allowed. While this may be true of your data stored based on the GUID, the JWT approach does not require server state - so it scales far better - and accomplishes the same thing.
The general "Authentication with Token" approach is very good but you shouldn't try to make Basic Authentication work in different way than it is supposed to (after all it is a defined standard). You should rather use your own header for authentication purposes. You can find a very good description of such scenario here:
Making your ASP.NET Web API’s secure