HMAC-authenticated requests on GCS JSON API - google-cloud-storage

In GCS "migration mode", it's possible to send HMAC authenticated requests to the XML API (since it's S3 compatible). Is it possible to do the same (HMAC authenticated requests) for the JSON API too?

The JSON API does not support HMAC authentication.

Related

Describing contents of JWT token in OpenAPI

I am building a REST API that uses data in the JWT token to perform some operations. (E.g. verifying the ownership of the data, so for some cases, I might send user_id or something like that in the JWT token).
Is that possible to describe the expected contents of the JWT token using OpenAPI?
This is not supported as of OpenAPI 3.1, but there's an existing feature request:
Allow payload definition for JWT schema

JWT - asymmetric encryption

I have three servers:
- authorization server
- api server
- frontend server
Authorization server returns JWT self-contained access token (+refresh token). JWTs aren't stored anywhere in Authorization Server.
I want to secure JWT with asymmetric encryption and i am not sure if i my idea is correct.
Let me describe flow:
After login from Fronted Server, Authorization server gets user credentials, then generates JWT token and encode it with public key.
Fronted Server receives encrypted JWT token and client (web browser) saves it as HTTP-Only cookie.
Client sends request to secured resource, so FrontEnd based on obtained encoded JWT token, requests for secured data API Server.
API Server based on secured JWT and private key decrypt value and checks if user has enough access to perform operation.
If JWT token expires, front end sends request to Authorization Server with refresh token to get new JWT token.
In this case Authorization Server and API Server would need to store private key for decryption.
Is this solution secure enough? Is it OK to store the same private key in two servers?
Do you know if flow is correct? Or maybe data flow should be different?
I want to secure JWT with asymmetric encryption and i am not sure if i my idea is correct.
In general, data encryption is a good idea. Especially if you transport sensitive data.
Let me describe flow
[…]
In this case Authorization Server and API Server would need to store private key for decryption. Is this solution secure enough? Is it OK to store the same private key in two servers? Do you know if flow is correct? Or maybe data flow should be different?
If I understand correctly your flow, the token is encrypted on AS (Authorization Server) side and decrypted on API server side. Therefore you want to prevent the client from reading its content.
This flow is absolutely fine. Both the AS and the API server will have the shared secret so that they will be able to encrypt or decrypt the token.
I suggest you to read more about JWE (encrypted JWT) and the associated RFC7516. This specification describes a standard way to encrypt tokens.
Depending on the programming language you use, you may found libraries that support JWE. https://jwt.io/ lists lot of libraries and some of these support more than signed tokens (JWS). For example com.nimbusds/nimbus-jose-jwt (Java) or web-token/jwt-framework (PHP).
A possible flow could be as follow. Please not that it will undoubtedly create complexity in your AS and API server code. So before you implement it, you should make sure it is necessary to encrypt your tokens! (e.g. you transport sensitive data)
The AS sign the token with its private key (e.g. algorithm RSxxx, PSxxx or ESxxx) => JWS
The JWS is encrypted as per the RFC7516 with an asymmetric encryption algorithm (e.g. AxxxKW or AxxxGCMKW) and the shared key => Nested token (a JWS in a JWE)
The Nested token is sent to the client
The client cannot read the content, but the token can be sent to the API server as usual
The API server decrypts the JWE with the shared key to get the JWS
The API server verifies the JWS with the AS public key

registering a rest API with OAuth

I have written a web application which makes REST API calls to a message broker. The message broker contains already written REST APIs to which can be used to get message broker data. The message broker is written in a way in which each REST API call sends the user name and password which is encoded with base64. I need to make a login to my web app and authenticate it with OAuth.Does anyone know how to do this? How to authenticate the REST APIs with OAuth?
Step 1: Add OAuth 2.0 to your web server. This is very standard with lots of libraries available. You did not specify the Identity Provider that you will use (Google, Facebook, Auth0, Okta, etc), but each vendor has documents and libraries for you to use in your desired language.
Step 2: Add an Authorization Header to your API calls. The standard method is to add the HTTP header Authorization: Bearer access_token when making an API call.
Step 3: Add OAuth token verification to your API. When your API receives a request, it extracts the Authorization header and verifies the Bearer token. How this is done depends on the Identity Provider. For example, some vendors provide a Signed JWT (which you verify with the vendors public certificate), others provide an opaque access token (which you verify by calling the vendor's token endpoint). Add internal caching of tokens so that you don't need to verify on every API call.
If you understand OAuth 2.0 the above steps are straightforward to implement. If you don't Oracle has a set of videos which are excellent for getting started understanding OAuth.
Oracle Cloud Primers
If your desired OAuth implementation does not require users logging in and is a server to server service that you control on both ends, then you can use just part of OAuth which is Signed JWT (JWS). You create a Json data structure with your desired content and sign it with a private key. This creates a token that you can use in the above steps. You would then validate the token using your public key. You can use self-generated keypairs generated by OpenSSL or similar products for your signing and verification.

Is it secure to send authentication token in HTTP/S response body?

In order to put some additional Information about the access- and refresh-token in a REST API response, I thought about creating a token object, that carries all the information which I want to append to the token and send it along with the usual JSON response.
Would this be less secure? If yes, why and how could I work around the security leak?
Well its possible to decrypt SSL traffic using Wireshark. You should encrypt your access token before sending it to the client in api response

JWT. Why is it better than oAuth and what's the signature?

I'm reading about JWT and I'm confused about why there's a signature:
JWT site
What is the purpose of the signature if it's just a hashed version of the header and payload?
Also, why not just use oAuth? Or whatever 2 factor auth uses?
The purpose of Oauth2 and JWT is different, so it is not possible to compare them directly
JWT is a compact way of representing claims to be transferred between two parties (JSON with digital signature).
OAuth2 is an authorization framework used by third party applications (websites, mobile apps) to access on resources on a resource server, without exposing user password. OAuth2 can use JWT as the exchanged token
JWT is self contained and does not need server sessions . The digital signature is performed with server private key and protects the content. Any alteration of the header, the payload or the signature will be detected by the server and reject the token.