I am trying to secure an endpoint in spring boot using Azure spring boot libraries. I'm following the samples from https://github.com/microsoft/azure-spring-boot/tree/master/azure-spring-boot-samples/azure-active-directory-spring-boot-sample
I can't get a clear answer if I should use Id_token or Access_token when making the API call from my front end application written in React.
https://learn.microsoft.com/en-us/azure/active-directory/develop/access-tokens
I think docs from this link above states that I should use Access_token to secure the endpoints but, in that azure-spring-boot-samples, they used id_token to make the API calls.
I've tried to use the same code and test an API call. API call is successful if I use id_token in header. It fails signature check if I pass access_token in header.
I figured this out after understanding the big picture. All applications either front end or back end most likely should be using different app IDs. On Azure portal I would define which app have permission to call which API. Then, when I get access token, I would have to specify what app I am getting access to. This is laid out in MSAL doc from Microsoft. https://learn.microsoft.com/en-us/azure/active-directory/develop/msal-acquire-cache-tokens
Also, only the access_token allows you to assert claims for things like Role Based Access Control in the token. The ID token is usually shorter lived and has less information. In general it is a better practice to use the access_token.
Related
I want to use auth from google firebase, and integrate it with spring boot.
I am not sure that I have good idea how to implement roles/authorities.
I have in mind this scenario:
On success authentication with firebase, frontend send request to secured spring backend endpoint, and data on this endpoint contains which roles should user have, so frontend use this data to set claims for user. Backend use claims to authorize user when accessing endpoints.
Is this okey, or is there faster/better solution?
That sounds like a good approach. Have a look at the Firebase documentation on verifying ID tokens as that'll be your starting point once your backend receives the token from the client.
The only addition I can make at this point is that many of Firebase's own backend services cache recently decoded tokens (with the undecoded token as the key) to allow subsequent requests to more quickly look up the information for that token. While this is not required, it's an easy speed up once you're ready for that.
I'm working on an Absinthe GraphQL API for my app. I'm still learning the procedure(so please go easy on me).
I've a Absinthe/GraphQL MyAppWeb.schema.ex file in which I use for my queries and mutations. My question is how do I use this API for authenticating the user on both Mobile and Web app?
How do set a cookie(httpOnly & secure) in my web app and access/refresh tokens in a single Absinthe API to serve my website and mobile app. Basically what I'm trying to learn is how do I authenticate the user based on specific platform.
If my question sounds bit confusing, I would be happy to provide more information related to my question. I would really be grateful if someone could explain the procedure, I've been very stuck on this for a while.
I would avoid using authentication mechanisms provided by absinthe(if there are any). Depending on what front-end you are using, I would go with JSON API authentication. The flow on server goes the following way:
Create a endpoint for login that will receive a user and password and will return a refresh token.
Create a endpoint for exchanging refresh token for access token.
Use a library like guardian to generate your refresh/access tokens.
Create a phoenix plug for authentication that will check your tokens, guardian has some built-in plugs for this.
Now on device you have to implement:
Ability to save refresh and access token on device.
Have a global handler for injecting access token on authorized requests.
Have a global handler for case when access token is expired. (you usually check if your request returns Unauthorized, then you should request a new access token from the server using your refresh token)
This seems like a crude implementation, however I would advise in implementing your system instead of using a black box library that you have no idea how it works under the hood.
I don't want to roll my own security anymore and am looking at using OpenID Connect with my c# API and AngularJS app. I can get all that to work just fine. However, my brain cannot seem to understand how to secure my API correctly for both use cases:
Use Case 1: AngularJS SPA
My AngularJS app connects to my API and sends a bearer token identifying the user and includes user claims. This one is easy and there is tons of documentation on it.
Use Case 2: API to API
Some customers want to access my API directly instead of going through my AngularJS app. In this case, I thought I could use a Client ID/Secret for toen-based authentication which is great except then I know nothing about the user that's using the client id/secret. There could be 10 users using the same custom API that is calling my API. How do I get user info via the API call? I've seen others use API keys that they then lookup the user and create a JWT but I thought there might be an easier way. Any ideas?
The whole point of API to API authentication is that there is no user context. Or well, the user in that case is the machine trying to access your API. You would then need to design your authorization logic around that and implement scope based permissions. Alternatively, your options are to use api keys as you mentioned or if you want OAuth protocol with user context in the api to api scenario - then ResourceOwnerCredentials flow is an option.
API to API communcation
You can use Client Credentials Grant defined through OAuth 2.0. This won't require you to have end user credentials. Now this won't be OpenID Connect. OpenID Connect require the involvement of an end user and bound to authentication. OAuth 2.0 on the other hand is about authorization, checking whether the entity can access the resource.
With Client Credential Grant, your identity server will issue tokens for a specific client. So one of your API becomes the client (resource consumer). From request handling API endpoint, you can accept valid tokens and respond back with resource.
If you require fine grained access control from request handling API, you will require to use token introspection to identify to whom this token was issued. In this case, it will be identification of specific client identity and execute a logic on top of it. You can check the token introspection response to identify such details.
Alternatively, access tokens can be come in form of a JWT. If this is the case, they can be considered as self contained tokens so validation is straightforward.
I want to use Ionic to connect with a Laravel rest API. As far as I know I should use OAuth to authenticate the user. How does this stop other clients/requests from accessing my rest API?
For instance if someone created another Ionic app or anything and requested a OAuth token.
AFAIK there's still no way to perfectly protect your API source. As you mentioned, OAuth is one way to help protection.
I often use JWT, aka. JSON Web Token with token-refresh which expires right after one use. You can check out my short tutorial on using JWT with Laravel and AngularJS, which is absolutely same with Ionic.
I’m trying to get my head around how I would introduce token-based (key-based?) authentication to a web API (currently looking at Sinatra, but maybe Rails too) that would be used by a mobile client and how OAuth would fit into the picture.
So, let’s say I want to create a web service that uses Facebook for authentication and grabbing basic user data. Here, my API would be a client to Facebook’s OAuth Server, requesting an access token upon a user’s successful login to Facebook. This would then grant me access to the user’s data which I would use to create an entry in my database, storing this user-specific token with any other application information I would like linked to them.
I think I got that part right so far, but here’s where I’m a bit confused.
I think that my API would also need some form of API key to grant access to a mobile user, since I wouldn’t want to transmit and store the Facebook key on their device. Would I have to have a separate store of keys which I provide to the client to access my service? Are there any ‘best practice’ ways of doing this?
Would I have to have a separate store of keys which I provide to the client to access my service?
yes.
Are there any ‘best practice’ ways of doing this?
The simplest way would be to generate a separate authentication token on every User creation and expose that to the mobile client. Then send it with every subsequent request header.
Devise provides a simple example how to achieve that. You don't need devise for that, just provide some token generation mechanism.
#Devise.friendly_token
def self.friendly_token
SecureRandom.urlsafe_base64(15).tr('lIO0', 'sxyz')
end
This mechanism can be extended to provide more security in following ways
Being an oauth2 provider itself.
On successfull login with facebook, you would generate an :authorization_code which the client can exchange for your own Oauth2 Bearer or MAC token within a next step. Then you can send your own Oauth2 token with every request for user authentication.
See rack-oauth2
Implement HMAC token encryption.
Generate and expose a secret_key to every client after singning in. Use this secret to sign messages along with a unique client id. The server can then lookup the secret_key for the specific client_id and verify the message.
See api-auth