We're using Google Identity Platform (Firebase Authentication ft. Google Identity Toolkit) as IDaaS, mainly for SAML 2.0.
When an IdP returns an encrypted SAML response assertion, Identity Toolkit throws the following error: INVALID_IDP_RESPONSE has no assertions, but if assertions are not encrypted, everything seems to work fine.
So does Google Identity Platform supports encrypted assertions in SAMLresponse? Couldn't find anything in the documentation about whether it's supported or not.
Google Identity Platform does not support encrypted assertions in SAML responses. You can confirm this from the REST API for configuration SAML providers. Notice they don't provide a public key for IdP encryption (normally for encrypted SAML, the SP would generate an asymmetric key pair, they would keep the private key and you would configure the public key for encryption with your IdP).
Related
I am developing an app using microservices in NodeJS. I have built an auth api which handles the usual registration login etc and it issues JWT's
How do I use these to protect routes in a separate API microservice written with Express?
Do I need to use JWT with the secret to decrypt the token in the API app?
You could write a library that you import into your other microservices that requires all routes by default to require authentication. This library could have a mechanism to validate JWT's at the microservice level, so you never need to talk to your auth api to see if a JWT is valid or not. See the description and diagram below:
Your auth server will will need to be the single issuer of JWTs to your microservices. So, when a user logs in and successfully authenticates, your auth server will issue a JWT signed with a private key (signing MUST be asymmetric - RS256 is one example) you keep on the auth server only; do not give this private key to other microservices that you wish to validate JWTs inside of. What you can do is derive a public key based on the private key you sign your tokens with and publish that to an endpoint on your auth server that requires no authentication - the public key will be represented in the form of a JWK (see link to spec). Google does something similar here. Then, in each of your microservices, your library will need to devise a way to make a GET request to the public key endpoint on your auth server every X minutes to see if there are any changes and cache the public key in each microservice. By having the public key cached in your microservice, you will be able to validate the requesting JWT inside the service that is being requested.
Then whenever a request comes into one of your microservices, the library you import will examine the requesting JWT, check its validity, and grant access/authorization if the token is valid. The beauty of using a private/public key pair and asymmetric key signing is that you can validate a token based on the public key alone, but not sign it. So as long as each service has the public key from your /cert endpoint, they can validate a token without ever needing to talk to the auth server or knowing the private key.
This will require a little more work up front, but will yield you massive amount of ease, flexibility, and peace of mind in the future knowing only one source knows your private key.
One common pattern here would be to use an API gateway as the entry point to your entire microservice architecture. Incoming requests for authentication would be routed to the appropriate microservice. If the credentials provided be correct, a new JWT would be returned to the gateway, which would then forward to the caller. For the actual microservice APIs which comprise your application, the gateway would check that the incoming JWT be valid before allowing the request to hit the microservice.
This answer leaves out a few things, for simplicity. For instance, often you would want to have an authorization microservice, which decides what a user is allowed to do. Also, implementing JWT can be involved. You might need a cache layer to keep track of whitelisted and/or blacklisted JWT.
Here is the solution I came up with, to handle user data we can implement an Identity Provider Service (IDP) which is responsible for signing JWTs with symmetrical keys (rs256) and storing user information. The Identity Provider also has an open endpoint which will expose the public key in the form of a JWK (JSON Web Key) which is used to sign the JWT, This endpoint can be used to validate issued keys by any other service (ideally the external service would cache the JWK to reduce traffic to the IDP).
But This also poses another issue, that is we will have to implement more code to validate the tokens with the JWK endpoint. This is where an API Gateway comes in, The API gateway sits between the frontend client and the API server acting as a checkpoint. The API Gateway caches the JWK using the IDP endpoint and validates all the incoming requests. This means we would only have to implement features like JWK validation, rate-limiting, and SSL only to the API Gateway and we will not have to rely on the internal services for implementing these. Plus another improvement to the API Gateway would be to write the decoded JWT data onto the headers so the API Gateway can pass the decoded data for example: x-jwt-email: person#email.com directly to the internal services.
I found inspiration for this implementation from various sources and this was one of the first system designs that have completed building so let me know if there are any loopholes or improvements that could be implemented.
The code for the above implementation can be found here:
Identity Provider
API Gateway
My users are logging in using custom authentication system on my website, which is returning JWT signed by my company's private key.
I'm trying to enable users to login to Firebase as described in Authenticate with Firebase in JavaScript Using a Custom Authentication System.
If I understand correctly by reading the instruction I'm supposed to:
create service account in Firebase
download its private key
copy the private key to my authentication server
sign JWTs using this key
However, I need to stick to using my company's key to sign JWT.
Is it possible? If so, how can I provide my company's public key to Firebase for it to be able to decode my JWT? Or is my understanding about the flow wrong?
There is no way to specify what key Firebase should use for decoding the JWT. The requirement also doesn't make sense, since you're interacting with Firebase's backend services. If you interact with multiple backend systems, you'll need to mint a separate token for each.
We are working in an iOS application and we use back-end in azure. We have 2 types of login, one is Facebook login (using Fb as identity provider) and the other will be login directly to our system.
We decided to use ACS but we had a bunch of technical problems. My question is is it possible to create custom identity provider, which will be a service (for example WCF or WEB API) to generate a token that we pass the ACS to get the claim token. Does ACS support that kind of service interface? If so what what is the practice of generating tokens in our custom identity provider?
Thanks in advance,
Deuce
ACS can support any identity provider that speaks a protocol it understands. Depending on the backend behind your identity provider, you can use something like ADFS or write your own identity provider using WIF. ACS doesn't support mixing and matching web-based identity providers with WCF-based ones, which means that you'll need to expose a website that ACS can redirect a browser to using the WS-Federation protocol. The only external contract you have is that ACS will redirect users to you and you need to log them in (what that means for your IdP is up to you) and issue a token back to ACS.
There are literally whole books on how to write your own STS using WIF, to get started there are a number of resources that can help, including the WIF SDK (which provides a template for the STS), this whitepaper (see the section "Using Windows Identity Foundation to Build a Security Token Service"), or this blog post.
So evidently when using OAuth 1.0 you need to acquire consumer key and consumer secret from the API provider...
But then when I try to use OAuth 2.0 APIs such as Facebook, Google Oauth 2.0, etc I never needed to acquire consumer key/consumer secret (I acquired App ID and App secret for Facebook, but those are different from consumer key/consumer secret am I correct?)
So my question is...is it true that when using Oauth 2.0, you don't need to have a consumer key/consumer secret as in Oauth 1.0
Also there are no signature methods (HMAC-SHA1 etc) necessary for Oauth 2.0, is that correct? HMAC-SHA1 is only relevant for Oauth 1.0, correct?
OAuth 2 providers typically issue you an identifier for your client/app and some secret/password, the OAuth draft calls these client identifier and client secret. These are used to check if a call was really issued by your application. However, OAuth covers different Authorization Grant flows which are more or less secure and do not all require some kind of secret. Google calls them client ID and client secret, Facebook calls them App ID and App Secret, but they are both the same.
Yes, all cryptographic steps were moved to server side in OAuth 2.
The authorization grant flow that you are referring to is known as the Client Credentials Grant flow in the OAuth 2 specification. It is used to do application-only authentication. Meaning that no user is involved. A typical example is the display of a twitter feed on a home page.
Normally the application passes both consumer key (or app ID) and consumer secret (or app secret) over HTTPS to the server. This request is only protected by HTTPS; there is no additional encryption. The server returns a token that you can use from that point on to make requests to the API - given it does not require a user context.
The consumer key (or app ID) identifies your application and may have a meaningful value. You normally don't (or can't) change this anymore. The consumer secret however can be regenerated in case you believe it has been compromised. This explains why there are two keys.
Regenerating the consumer secret is different from invalidating the token which won't help you if the consumer key and consumer secret have been compromised.
Both are same. the terminology used are different by apps/users/clients. thats it.Both are same.
I am building a muli-tenant saas(software as a service) architecture. I have to build the authentication system for the system.
From what I have studied, I think I need to the build the authentication system based on OAuth2.0 and the bearer token with JWT tokens.
After reading a lot about OAuth2.0 of how to build an OAuth2.0 server I still didn't understand the full concept of OAuth and also have confusion about whether I need it or not or I need some other Authentication system.
What my system need is we will provide an SDK to all our customer and each client will have an Application Id and a secret key using the SDK client will connect to his application present in our system.
The application ID will map the customer to his application present in our system and the client secret key will authenticate the client inside the application.Do I still need to build an authentication system based on OAuth2.0 or can I build my own authentication system based on our need?
What are the use cases of OAUTH2.0 and when we won't need it to implement?
First, as clearly indicated in OAuth authentication
OAuth 2.0 is not an authentication protocol.
Authentication in the context of a user accessing an application tells an application who the current user is and whether or not they're present. A full authentication protocol will probably also tell you a number of attributes about this user, such as a unique identifier, an email address, and what to call them when the application says "Good Morning".
However, OAuth tells the application none of that.
OAuth says absolutely nothing about the user, nor does it say how the user proved their presence or even if they're still there.
As far as an OAuth client is concerned, it asked for a token, got a token, and eventually used that token to access some API. It doesn't know anything about who authorized the application or if there was even a user there at all.
There is a standard for user authentication using OAuth: OpenID Connect, compatible with OAuth2.
The OpenID Connect ID Token is a signed JSON Web Token (JWT) that is given to the client application along side the regular OAuth access token.
The ID Token contains a set of claims about the authentication session, including an identifier for the user (sub), the identifier for the identity provider who issued the token (iss), and the identifier of the client for which this token was created (aud).
In Go, you can look at coreos/dex, an OpenID Connect Identity (OIDC) and OAuth 2.0 Provider with Pluggable Connector.