我需要创建一个公司的应用程序，他们希望让人们登录到应用程序有不同的权限来执行不同的任务。
我最初的想法是创建一个MySQL数据库，硬编码的凭据到应用程序，并有应用程序连接到MySQL数据库。 然后，MySQL数据库将有一个名为“用户”，这将存储用户名，密码和权限表。 然后，应用程序将查询服务器，并进行认证。
这样做的最大的问题是具有MySQL的凭据硬编码到应用程序。 如果应用程序获取落入坏人之手，如果他们窥探找到凭据，并开始删除表，他们可以做很多的MySQL数据库损坏。
因此，我认为开发充当MySQL数据库接口的服务器。 例如，客户端应用程序将通过TCP连接到服务器，并且服务器连接到MySQL数据库。 这样，MySQL的凭据不会暴露给最终用户。 但是，这意味着我必须开发出一个）将很难维护和部署，为我的客户（而不是仅仅建立一个MySQL服务器）和B）有潜力推出更多的错误，因为我有一个额外的系统中的服务器应用程序我需要（这涉及回点了部署错误修正等）
所以我在想有在数据库中的用户表，并让应用程序直接连接到与硬编码的凭据MySQL服务器的替代，最终用户将给予在他们将进入到连接到应用实际的MySQL用户凭据MySQL服务器。 这意味着，如果有人得到他们的双手上的应用，他们不能做的MySQL数据库的任何损害，但仍然存在一个最终用户给他们的凭据错人的风险。
什么是有一个桌面应用程序连接到MySQL数据库的最佳途径？ 是否有任何其他解决方案，以3比我也曾想过其他，还是你对我的解决方案有什么想法？
作为@Perception指出。 这里最好的办法是在MySQL的面前来实现Web服务。 你不希望客户数目不详来自未知IP地址的所有访问您的数据库。
这将是捆绑的MySQL连接很容易DOS攻击你。 更何况，你会很严重地限制您扩展您的后端服务，以满足客户增加底座的需求，而无需在两者之间有一个Web服务的能力。
Web服务也可以为您提供以控制任意数量的方式（用户名/密码组合，基于令牌的访问，OAuth访问等），用户认证和授权的能力。
我工作的地方有我已经看到了两个做法：
每个实体（人，物，或业务（根据所需粒度级别）访问数据库）有他们自己的凭据。 这是上MSSQL和火箭宇宙数据库上使用。 这主要是零售和传统软件。
我们举办我们自己的应用程序，并使用独立的身份验证系统用户。 数据库证书存储在我们的服务器在应用程序托管在。 客户端一无所知的支持数据库。 这些通常是Web应用程序和Web服务。
有些事情，你能做到这一点，我们做的是，我们的许多应用程序实际上是通过模仿数据库的方式RESTful服务交谈。 应用程序本身具有对数据库的访问权限。 我会读上RESTful服务维基百科的文章以了解更多信息。 我们的认证使用是每个用户给他们自己的钥匙绑在他们的凭据杜撰编码HMAC请求完成。
在Web服务包装数据库为您提供了一些可能的优点：
- 如果你决定改变你的数据库结构，同时保持相同的信息，你甚至不需要更新客户端应用程序，只是服务。
- 证书从未离开服务器，您的凭据保持安全，只要没有人获得访问自己的服务器。 一般安全性增加。
- 如果你做你的服务够巧妙，你甚至可以传递很多的内在逻辑，通常会是客户端到服务器，进行更新和错误修正几乎无缝的客户端。
我看到的缺点：
- 这是一两件事，以保持
- 您的应用程序容易受到拒绝服务攻击，但因为它是这是一个可能的问题，反正数据库
- 如果服务器出现故障，所有的客户端应用程序走下来，但同样，还是个问题呢。
RESTful架构： http://en.wikipedia.org/wiki/Representational_state_transfer
HMAC： http://en.wikipedia.org/wiki/Hash-based_message_authentication_code
我们HMAC系统的工作原理如下所示：
- 使用用户名和密码的本地应用程序用户登录。
- 本地应用程序通信，我们的认证服务，并得到了“会话密钥”，并为用户名和密码共享密钥。
- 使用会话密钥（在很短的时间段到期），应用程序创建的API密钥（其持续很长一段时间），并将其存储到计算机。 如果每次都要登录时间要求用户的会话密钥可以用来代替的API密钥。 我们主要做了这种方式方便了一些程序。 如果计算机是不安全的，会话密钥只应该用于没有API密钥存储在本地计算机上。 每次用户登录的时候，他们得到一个新的会话密钥。
- 到数据库中每个服务请求是伴随着一个HMAC签名现时该应用程序基于API密钥的授权服务获取。 获得随机数后，应用程序签名使用共享的秘密吧。 这些签名的请求只能因为Web服务（用户可能一无所知）认证要求使用一次。 一旦签署现时已经看到，如果散列与特定API的乱数/会话密钥在相同的共享秘密结果消化认证服务器端，现时被标记过期，要求是理所当然的。
以上是脆弱的人在这方面的中间人攻击，如果不使用HTTPS，所以人们往往使一个时间戳一起被请求的基础上，随机数和URL信息和计算上的HMAC。 然后，服务器将重新创建基于URL的消息，检查以查看是否时间戳是一些范围内（+/- 4mins或东西），然后授权基于该信息的用户。
为了进一步颗粒操作，我们也有一个角色系统检查，看是否谁拥有会话的用户/ API密钥已被赋予权限申请，他们要求的东西。 如果他们有合适的角色，该请求被批准。
摘要 ：凭据完成用户通过用户，最终用户没有数据库的知识，Web服务封装在一个RESTful API，数据库，基于角色的系统，用于进行权限粒度。
这仅仅是一个建议，我不是说这是做到这一点的最好或唯一途径。 这恰恰是我们如何落得这样做是我工作的地方。
让我们来看看处理数据库的方法有两种：
- 客户端直接连接数据库 ，操作数据库
- 服务器连接到数据库，并提供接口的客户端使用
考虑到你的使用情况：
有效有效的序列号或存储/读取关于特定用户的信息
它可以通过以下方式来提供安全性设计。 （我在这方面的专家）
- 客户端直接连接数据库，操作数据库
- 你没有使用你的管理员访问数据库，而不是您创建客户端的用户只，并限制用户的访问权限 ，只查看（某些数据）。 你可以通过更改权限此用户在数据库中执行安全政策。
- 你可以咨询的MySQL :: MySQL 5.1中参考手册:: 6安全性的更多信息。
- 6.2 MySQL访问权限系统
- 6.3 MySQL用户账户管理
- 服务器连接到数据库，并提供接口的客户端使用
- 您可以使用HTTP和客户使用提供接口。 而且，只有后端连接到数据库。
- 喜欢的RESTful API的东西，也有很多易于使用的框架，它提供身份验证和授权。
我不认为这是个好主意，让客户在你的情况下直接访问数据库。 因此，如果可能的话，第二个选项是更好的。
还要注意的是基于密码的认证是不理想的。
