I am creating a web application, I am enabled the login with google openid connect and it is working. Now I want to protect the resources (rest api) with the access_token but I am not finding how to pass a custom audience (https://api.myapp.com) and custom scopes (read:users add:users) to create the access_token, is it possible create custom audience and scope by google openid connect to protect my resources?
If I dont validate the access_token (audience and scopes) I can compromise my web application.
See the below image.
Thanks in advance.
Regards,
Arsenio
Related
We have a SPA web application that supports OpenID Connect login from external Identity providers. Our application supports different user types (roles). We want to support Sign in with Google using Google Identity service (https://developers.google.com/identity/protocols/oauth2/openid-connect) but the Access Token seems to be for Google APIs only (we want to protect our own APIs). The ID Token is a JWT we can validate, but there is nothing in the claims we can use for Authorization.
Is it possible to add custom claims to the Google ID token that we can use for Authorization?
From the link above...
This document describes our OAuth 2.0 implementation for authentication, which conforms to the OpenID Connect specification, and is OpenID Certified
I guess this means they ONLY support Authentication and not Authorization? Is this true? Or is there some other Google service we need to use to get user roles (Google Cloud IAM, etc.)?
How does Google expect us to Authorize users they Authenticate?
To get control over what the tokens contains, then my recommendation is to add a separate identity provider in-between your applications and Google. In this way, your applications only need to trust your local provider and it can provide the tokens that you need and you can add additional user information/claims to the tokens.
Just like this picture tries to show:
I find keycloak restful authentication api in postman，like this:
I know this api will return keycloak token if I give correct username and password. But now, I want to custom a api to let keycloak to finish authenticate like this, then I can obtain a keycloak token.
I read keycloak doc, but I think authentication spi can't achieve.
Is there a way to achieve this?
Adding a new API (rest endpoint) to Keycloak is possible, but you should not (and probably can not) use it to add such a custom authentication. Keycloak as an identity provider is OAuth/OIDC Connect compliant and the endpoints to get/exchange a token are all part of those specifications. So if you want to protect your API using a token provided by Keycloak, you should follow the steps specified on those specs. I suggest you to read a couple of OAuth/OpenID Connect tutorials on the Internet or have a look at a post like this. You should first decided what OAuth flow matches your use-case. Then you can go to the Keycloak console and configure clients for your applications. I guess probably you would need one for the caller and one for the service that is going to be called so that they could authenticate themselves to Keycloak. I don't think that for your scenario, you would need any customization on Keycloak.
I'm having the following scenario:
A frontend SPA based on Vue.
A Nest.js-Application providing an API
The user should authenticate against the Nest.js Application with Azure AD.
The Nest.js Application should provides several Endpoints where other Apis (e.g LinkedIn or Graph) should be consumed.
My Question now is if this scenario is realizable and if yes how do I have to implement the Authentication for the External Apis which are consumed by the Nest-Application?
Many thanks in advance
If I understand you correctly, you want users to be able to authenticate with Azure AD, LinkedIn e.t.c. for LinkedIn you can use http://www.passportjs.org/packages/passport-linkedin-oauth2/, the goal is to get a token that contains the user's information after authorization with these external APIs on the backend, you have to set a URL on the backend that points to the frontend with the token appended, on the frontend, you need to provide the callback URL, get the token from the URL, then you do a redirect.
I'm developing a common auth service for several different web services. The general idea is that a user goes to one of these web services and clicks on a login button and gets redirected to my auth service. Once authenticated, the auth service redirects the user back to the original web service.
To begin with, the auth service will use Google's OpenID Connect service. One idea I had was that when a user was authenticated using Google I could pass around the resulting JWT to other services to use as an auth token. Google mentions this idea in their documentation (https://developers.google.com/accounts/docs/OAuth2Login#validatinganidtoken):
One thing that makes ID tokens useful is that fact that you can pass them around different components of your app. This can be helpful because different components of your application may pass the ID token between them and use it as a lightweight authentication mechanism authenticating the app and the user.
Can anyone help me with the actual details on how this should work e.g. How do I handle log outs both on Google and from the auth service? There appeared to be some documentation on this in older OpenID Connect Session documents (-03) but it appears to have been removed.
You should not pass the ID Token that you receive to Google back to the app to use as an auth token. The ID Token will have an audience specific to your app, not the ultimate client.
If you just passed this back to clientA, then you would open it up to auth attacks where clientB could obtain an Google ID Token via your auth service and then use that token to gain access to user data in clientA.
A much better approach would be to mint your own ID Token and provide an audience designation for each app that uses your service.
Monitoring session state is not as straightforward. The easiest thing to do is for your service to wrap G+ sign-in libraries and interface with the session state api's.
https://developers.google.com/+/web/signin/session-state
I'm gonna try to explain my problem :
I'd like to allow users to connect to my api via their own accounts (login/password) or via a social network (Facebook at first).
Then, I would allow any application to use my api, with the user authenticated.
My first thought when to auth the user via his/her login/password and return a token used as the session for the next requests.
But OAuth would seems to be the better implementations, except I don't know how to do this :
One of my applications will have to connect via login/password, like twitter web (I have to implement an login/password auth somewhere if I wan't my user to login :p)
Will I also have to register my applications to the oauth system (did twitter added their web app to their oauth ?)
How to merge the auth via others social networks. Concretely, the user will have to OAuth to my api that will auth to the social network.
I'm a bit lost on how to do this, if someone could help me, I would really appreciate !
Thanks
Update 1:
Flickr and Lastfm seems to not use OAuth but an alternative auth system that looks like this :
The user is redirected to Flickr/Lastfm
The user auth himself and accept to use the application
Flickr/Lastfm return to the Callback url with a temporary frob (for flickr) or token (for lastfm)
The app must call the provider with the temporary frob/token (among with the api_key and the api_sig, as always) and get in return the session token to use for the next calls.
Update 2:
In fact, StackApps is the concrete case of my problem : you can login through their login/password system OR openId, and you can use their API.
OAuth is only needed to make others use your API on other services, i.e. authorize services to use your API without users of the intermediary service explicitly having to log in into your service by giving user's login credentials to a third party.
What I think you need is OpenID, the cross-application authentication mechanism. You just need to implement an OpenID client, accepting third-party OpenIDs to authenticate users, to subsequently identify them, when they use your service's API. This would have to be supplemented with a normal 'local' user authentication mechanism (i.e. login/password entry page)
You will need OAuth to provide an ability to use your API on other sites, though.