In Auth0 there are 2 algorithms for jwt token signature: RS256 and HS256.
RS256 is an asymmetric algorithm which means that there are two keys: one public and one private (secret). Auth0 has the secret key, which is used to generate the signature, and the consumer of the JWT has the public key, which is used to validate the signature.
HS256 is a symmetric algorithm which means that there is only one secret key, shared between the two parties. The same key is used both to generate the signature and to validate it. Special care should be taken in order for the key to remain confidential.
In their docs they describe the advantages of RS256. Could someone explain me the advantages to use HS256 algorithm, I don't see them now but I'm pretty sure that there are some.
You have asked for benefits of HS256 over RS256 eg.
perceived convenience
easy to understand and get started with if new
to Oauth2 / OIDC (related to perceived convenience)
performance (?)
Lets take a quick look at each of these:
Perceived convenience / understand what to do - It is true that copying a clientId, and clientSecret into configuration on the application is both easy to understand, and quick accomplish. However, today's libraries make RS256 simple too to setup - the library / framework will often offer the functionality to retrieve the public key and do the verification with similar configuration to HS256 but without the need to supply a secret. See some Auth0 examples using your technology choice to get an understanding on this if unfamiliar.
Performance - Yes, here HS256 potentially has a niche. Caching public certs etc aside (for caching example using node.js see here and here), having a symmetric key and using that locally at the application without the need for any network request at all etc, may prove more efficient. That said most good JWKS libraries / sdks will handle caching options out of the box.
But really the question you should be asking is whether these benefits (performance optimization?) outweigh the disadvantages - certainly from a Security perspective.
See this answer and feel free to leave comments there (Auth0 Community website) if still not convinced. Auth0 has switched to using RS256 by default for new Clients, and its Resource APIs also default to RS256.
A major benefit of RS256, which trumps most arguments for choosing HS256, is simply that there is no need to store (co-locate) secrets with the Client application - the private key is only known by the Authorization Server (Auth0 etc), and the secret cannot be leaked. That alone pretty much tells you why RS256 is overwhelmingly the better choice for most situations.
Confidential vs Public Clients - you should only even consider HS256 if your Client is considered a Confidential Client. Since confidential clients are capable of holding secrets, you can choose to have ID tokens issued to them that have been signed in one of two ways - for non-confidential clients, you should never be using HS256 as by definition the client is not capable of keeping the secret confidential.
There are other considerations that make HS256 a poorer choice too, for example the need to manually update all applications using a given Client configuration if there is a signing key rollover.
Related
We are an ISV building an enterprise SaaS product.
We would like to enable our customers define their IDP SAML configuration.
We are a startup and would like to support SAML as lean as possible.
1. What is the minimal configuration needed to support the major IDPs?
After reading Okta's article I understand that:
Certificate
IDP Sign-in URL
Are a must.
Say that we use a single ACS endpoint (We will implement our own logic by looking at the SAML assertion)
Is there anything else mandatory?
What about bindings? Do all major IDPs support HTTP redirect?
2. What is needed to be defined on the IDP side?
We tend to use the HTTP redirect binding, should it work with most IDPs? Is a metadata endpoint important?
As for "what is required": in many cases, you will have to generate so called "metadata.xml" file to provide the information to the vendor, so they might install a testing environment for you.
I've implemented about 5 SAML integrations with different vendors so far. The truth is that not all of them require full-fledged SAML 2.0 standard, but some of them do. I think my article should be also helpful to you https://dev.to/optiklab/working-example-of-saml-single-sign-on-integration-using-c-39mb and my open sourced SAML integration project (https://github.com/optiklab/SAML-integration-utilities) contains both Metadata File generator and C# examples for forming both SAML response and assertions. They proved to be working with many vendors, like Ping Identity, etc.
Let me know if you have more specific questions.
I have a simple websocket server and I currently XOR the bytes to provide simple encryption to prevent data tampering, sniffing, no AES, no other cipher algorithms - the key can be reverse engineered anyway. When I google "how to secure websockets" I get only one answer: SSL/TLS. Using SSL requires from me to generate certificates in order to use it and protocol handles encryption for me so I don't have to call my encrypt/decrypt functions myself. I don't understand the difference between those two approaches. Certificates ensure that the server we connect to is the right one am I right - they are like identification cards. But I'm confused. Do I really need SSL for my simple server? My client is written in C++, websocket server is on Node.js. I'm planning to make a webclient for it later.
SSL/TLS is correct and well vetted. The chances of creating a solution with equivalent security is close to 0. But perhaps you have many years of full time experience developing cryptographic solutions, but then this question would not be asked.
In answer to: "Do I really need SSL for my simple server?" Yes if you need security.
See the "Schneier's Law" comment,
Lately I have been reading a little bit about HATEOAS implementation in a HTTP JSON REST API(since I making one), and I understand the general concept of links and actions and so on and that there are many some different formats defined such as HAL, JSON API, etc.
What I don't understand yet is what the relationship between HATEOAS/REST and authentication is, or to make it into a more concrete question, what type of authentication should a "proper" HATEOAS/REST API use?
Obviously, it should be stateless, like a JWT token or something like that, but is there any standard and/or rules/guidelines or is authentication totally different subject?
Edit:
To clarify even further, my problem is not that I am having problems picking what authentication to implement, but that I do not know what is required from the API authentication-wise in order to be able to call it a REST/HATEOAS API.
So the (hypothetical) scenario would be: Create an API that can be said to be REST/HATEOAS in every sense of the word and get $1,000,000. Make one minor protocol-violating mistake and get $0. Meaning, the objective is not to do what makes the most sense, is the most efficient or what benefits the developers and/or users, but just to be 100% REST/HATEOAS beyond the shadow of a doubt.
Like you said, you should look at authentication in an independent manner.
It's true that token-based authentication systems implemented used by-value tokens do fit well in the stateless world of HTTP based API's so this could possibly be the recommendation to give for most common scenarios. However, you should look into the particular requirements of your scenario to reach a final decision, maybe there's a simpler option available like API keys.
Have in mind that if you choose a token-based approach there's still a lot to consider thereafter. Your API won't be of much use if you don't define a way for applications to obtain access tokens and there are many ways you can go about this, for example:
You could roll your own system and define your own processes around how the tokens are obtained and then used by the API in order to perform authentication
⤷ (not recommend, time consuming and easy to get something wrong)
Implement an identity provider/authorization server system compliant with available authentication standards like OpenID Connect and OAuth 2.0
⤷ (time consuming and complex, but by following standards you're less likely to mess up and you'll also gain interoperability)
Delegate the authentication to a third-party authentication provider like Auth0
⤷ (easy to get started, depending on amount of usage it will cost you money instead of time)
Disclosure: I'm an Auth0 engineer.
I couldn't find an information about in in Google. We are generating PGP key pairs using Bouncy Castle library and implementing our own "web of trust". I wonder if it is possible to use these keys for JWT also, or I need to use a PKI X509 certificates?
Thanks
The signature and encryption algorithms officially supported are listed here.
No signature or encryption algorithm using PGP is listed.
But nothing prevent you from implementing a new signature/encryption algorithm used by your server and clients.
AFAIK, there is no implementation at the moment that uses GPG.
From my point of view, you have to create a new key type (e.g. JWK with kty=PGP) and new alg (e.g. alg=PGP).
I am not an expert in SOAP, but from my knowledge SOAP is just an HTTP request formatted in XML in order to supply structured data.
I need to implement a simple API with a list of parameters.
I proposed using a simple REST interface, but I have been told that SOAP is more secure.
Any ideas on this topic?
My guess would be that you have been told SOAP is more secure because of the existence of various standards that relate to security:
http://en.wikipedia.org/wiki/WS-Trust
http://en.wikipedia.org/wiki/WS-Security
http://en.wikipedia.org/wiki/WS-SecureConversation
http://en.wikipedia.org/wiki/WS-Federation
Most REST implementations are based on HTTP which has Basic Auth, Digest Auth, SSL and OAuth as security related specs. Which is more secure is topic that is could be debated forever!
An important question is does your service need something more secure than online banks use? HTTPS seems to be sufficient for them, and they are a pretty big target.
No, it's not.
I can only guess why would anybody think the API flavor has any relevance in security, or safety (not the same thing, and it's not clear which one is referred to); it might be because the common misconception that REST means simply exposing your data objects. If that were the case, such an approach would surely be utterly unsafe! (in any meaning of the word)