I have developed a REST API which has been configured to only operate over HTTPS. The sole purpose of this API (at least for the moment) is to operate as the backend entry point for a mobile application.

I have rolled my own token authentication protocol (see this question/answers) which is used for client authentication. The main reason behind this was to be able to generate secure/re-usable tokens which the client could store locally & re-use on subsequent requests. As I have control over these tokens server side I have the ability to expire/invalidate forcing the client to re-authenticate (i.e. generate a new token) and I am also taking precautions to avoid the likes of MitM/Replay attacks. For this to work there has to be some sensitive information passed across the wire in plain-text, however, everything is running over SSL so AFAIK there isn't anything to worry about here(?).

There are a couple of parts to this current setup that do concern me though:

1. For server authentication, when the app receives the server certificate (self-signed) I am only checking whether the certificate subject (e.g. CN=domainname) is the same as the API address i.e. if the API entry point is api.mydomain.com then it must receive a certificate with a subject CN=api.mydomain.com otherwise the SSL session will fail.

2. There is no protection from the servers point of view from anonymous requests. Client authentication only happens at the point where the header/post information is inspected. I believe this could leave the door open to Dos attacks. Ideally I would like the server to only accept requests which come from a known source.

My concern with the first issue is it's far too easy to circumvent, the api address is configurable from the app settings & anyone can generate a self-signed certificate so it would be fairly trivial to trick the app into thinking it's talking to the correct server. The second issue is more just a general concern, however, if I could filter out any non-authenticated client requests it would be a bonus!

The only thing that springs to mind to solve (at least the 2nd problem) is to introduce client certificates. My concern with this is implementation time, complexity of deployment and management of the certificates themselves. I guess what I am looking for is some advice on whether (based on the current setup) introducing client certificates to the device would gain me anything here?

I have developed a REST API which has been configured to only operate over HTTPS. The sole purpose of this API (at least for the moment) is to operate as the backend entry point for a mobile application.

I have rolled my own token authentication protocol (see this question/answers) which is used for client authentication. The main reason behind this was to be able to generate secure/re-usable tokens which the client could store locally & re-use on subsequent requests. As I have control over these tokens server side I have the ability to expire/invalidate forcing the client to re-authenticate (i.e. generate a new token) and I am also taking precautions to avoid the likes of MitM/Replay attacks. For this to work there has to be some sensitive information passed across the wire in plain-text, however, everything is running over SSL so AFAIK there isn't anything to worry about here(?).

There are a couple of parts to this current setup that do concern me though:

1. For server authentication, when the app receives the server certificate (self-signed) I am only checking whether the certificate subject (e.g. CN=domainname) is the same as the API address i.e. if the API entry point is api.mydomain.com then it must receive a certificate with a subject CN=api.mydomain.com otherwise the SSL session will fail.

2. There is no protection from the servers point of view from anonymous requests. Client authentication only happens at the point where the header/post information is inspected. I believe this could leave the door open to Dos attacks. Ideally I would like the server to only accept requests which come from a known source.

My concern with the first issue is it's far too easy to circumvent, the api address is configurable from the app settings & anyone can generate a self-signed certificate so it would be fairly trivial to trick the app into thinking it's talking to the correct server. The second issue is more just a general concern, however, if I could filter out any non-authenticated client requests it would be a bonus!

The only thing that springs to mind to solve (at least the 2nd problem) is to introduce client certificates. My concern with this is implementation time, complexity of deployment and management of the certificates themselves. I guess what I am looking for is some advice on whether (based on the current setup) introducing client certificates to the device would gain me anything here?