Hello guys,
I’m currently using Oathkeeper as a reverse-proxy for protecting my API. I am really satisfied with the general functioning of the software. However I have an issue that only concerns the production: the default error message.
Obviously Oathkeeper generate it’s own error message but I have some problem with them.
Firstly
My first problem concerns the 404 error, when a user of my API wants to access a route that does not exists.
Currentlty Oathkeeper will respond something like that:
{
"error": {
"code": 404,
"status": "Not Found",
"message": "Requested url does not match any rules"
}
}
This message is ok for a development purpose but for production I would a prefer something like that: “The requested route does not exist. Make sure you are using the right path, domain, and port.” (Same as the admin 404 error)
Secondly
My second problem, the biggest one, is the internal error handling of Oathkeeper. For example when the query from Oathkeeper to Keto fail for whatsoever the reason, Oathkeeper will display a message like this one:
{
"error": {
"code": 500,
"message": "Post http://keto.auth.svc.cluster.local:4466/engines/acp/ory/glob/allowed: net/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers)"
}
}
Again this message is ok for development purpose but for production the reason of the crash should not be displayed (or less specific) and the internal url of the Keto service should not be displayed.
Thirdly
My third problem concern OAuth introspection error. When the user make a query with an invalid or expired bearer token, he will get this message:
{
"error": {
"code": 403,
"status": "Forbidden",
"reason": "Access token i says token is not active",
"message":"Access credentials are not sufficient to access this resource"
}
}
Once again, the “reason” is not production ready because the message specified is too specific. I would prefer something like “Invalid or expired token”
Fourthly
My last problem concerns the general form of the error messages, they are always with that template:
{
"error": {
"code": int,
"status": "string",
"reason": "string",
"message": "string"
}
}
In my case, our API is written using gRPC and the gateway generator plugin, so all errors generated from my API are using this template:
{
"error": "string",
"message": "string",
"code": int,
"details": ["string"]
}
This problem is not very important but for the end-user it’s not very convenient if he receives his errors under different forms
I hope that the lenght of my message won’t discourage you to read my post 
