凭证是指向主体名称提供应用程序声明证明的数据结构。应用程序使用凭证来建立其全局标识。此外，凭证还可用于确认实体的特权。
GSS-API 不提供凭证。凭证由那些以 GSS-API 为基础的安全机制在调用 GSS-API 函数之前创建。在许多情况下，用户会在登录时接收凭证。
指定的 GSS-API 凭证对于单个主体有效。单个凭证可以包含该主体的多个元素，每个元素由不同的机制创建。如果某个凭证是在包含多个安全机制的计算机上获取的，则该凭证在传输到包含其中部分机制的计算机上时有效。GSS-API 通过 gss_cred_id_t 结构访问凭证。此结构称为凭证句柄。凭证对于应用程序是不透明的。因此，应用程序无需知道指定凭证的具体信息。
凭证采用以下三种形式：
服务器和客户机都必须获取各自的凭证，然后才能建立安全上下文。应用程序可以在凭证到期之前重用它，在失效之后必须重新获取凭证。客户机使用的凭证与服务器使用的凭证可以具有不同的生命周期。
大多数情况下，只有上下文接受器（即服务器）才能调用 gss_acquire_cred()。上下文启动器（即客户机）通常在登录时接收凭证。因此，客户机通常会指定缺省凭证。服务器也可以跳过 gss_acquire_cred() 而使用其缺省凭证。
客户机的凭证用于向其他进程证明该客户机的身份。服务器在获取凭证后即可接受安全上下文。因此，如果某个客户机向服务器发出 ftp 请求，则表明该客户机可能已经在登录时获取了凭证。客户机尝试启动上下文时，GSS-API 会自动检索凭证。但是，服务器程序可以显式获取所请求服务 (ftp) 的凭证。
如果 gss_acquire_cred() 成功完成，将返回GSS_S_COMPLETE 。如果不能返回有效的凭证，将返回 GSS_S_NO_CRED。有关其他错误代码，请参见 gss_acquire_cred(3GSS) 手册页。有关示例，请参见第 8 章中的“获取凭证”。
gss_add_cred() 与 gss_acquire_cred() 类似。但是，gss_add_cred() 允许应用程序使用现有的凭证来创建新句柄或者添加新的凭证元素。如果将 GSS_C_NO_CREDENTIAL 指定为现有的凭证，则 gss_add_cred() 会根据缺省行为创建新凭证。有关更多信息，请参见 gss_add_cred(3GSS) 手册页。