I.はじめに
前、私は記事の共有リアルタイムでアプリケーションAsp.NetコアIdentityServer4権限ブロガーが私にボーの友人は私にシーンを求めている問題を、与えるその多くの記事を、私は彼に答えを与えますその後、私は自分のレビューを通じて学び、関連するソースコードを読んでいることを見つけ、完璧ではないIdentityServer4カスタム実装できるGrantTypeライセンス。
免責事項：あなたが私の最後の読んでいない場合は、これを読んだときに本当ののAsp.NetコアアプリケーションIdentityServer4権限の記事を、上記の記事は、この記事では、サポートのために、感謝をより明確になりますことを確認するために会場ください。注意をありがとう！
第二に、シミュレーションシーン
：記事は、以下のようなアーキテクチャは、マルチゲートウェイ・アーキテクチャに単一のゲートウェイ・アーキテクチャからの電力供給システムのアップグレードを入れています
しかし、上記の授权中心使用である密码授权模式が、のために微信小程序、微信公众号商城認可されたエンド使用は非常に適切ではありません、
微信小程序そして微信公众号マイクロモールクライアントのシナリオは以下の通りである：
ユーザアクセスがモールまたはマイクロチャネルの公共の番号モールが後になりますアプレット微信服务端関連するユーザーを取得するための認可を取得openId、unionId、userNameなど関連情報、そしてキャリーopenId、unionId、userNameおよびその他の情報アクセス授权中心ゲートウェイ、承認、成功したログイン認証およびその他の操作がある場合には、自動的に登録されたユーザーが存在しない場合。私は変換するために行うことをこのシーンの後授权中心のサービスを、それをゲートウェイ？研究と議論の後、私は以下のゲートウェイアーキテクチャ図に精製上記のチャートを置きます：
第三に、権限のアップグレード
当社のソリューションの最後の記事は、3つのプロジェクトに設立されました：
Jlion.NetCore.Identity.Service：授权中心ゲートウェイ-WebApiプロジェクトJlion.NetCore.Identity.UserApiService：用户业务网关-WebApiプロジェクトJlion.NetCore.Identity：基础类库主にこれを置くために公共インフラ層に使用されます
上記の需要シナリオ分析を通じて、我々は提示授权中心たちができるので、十分にこの要求をIdentityServer4カスタム認証方法のアップグレード上記シーンのニーズを満たすために。
ソースコードを表示した後、私たちは実装できることがわかっIExtensionGrantValidator達成し、実装するためのカスタム認証方法に抽象インタフェースをValidateAsyncする方法を、
今私は解決策にいるよ前授权中心で新しいプロジェクトWeiXinOpenGrantValidatorクラスコードは次のとおりです。
public class WeiXinOpenGrantValidator : IExtensionGrantValidator
{
public string GrantType => GrantTypeConstants.ResourceWeixinOpen;
public async Task ValidateAsync(ExtensionGrantValidationContext context)
{
try
{
#region 参数获取
var openId = context.Request.Raw[ParamConstants.OpenId];
var unionId = context.Request.Raw[ParamConstants.UnionId];
var userName = context.Request.Raw[ParamConstants.UserName];
#endregion
#region 通过openId和unionId 参数来进行数据库的相关验证
var claimList = await ValidateUserAsync(openId, unionId);
#endregion
#region 授权通过
//授权通过返回
context.Result = new GrantValidationResult
(
subject: openId,
authenticationMethod: "custom",
claims: claimList.ToArray()
);
#endregion
}
catch (Exception ex)
{
context.Result = new GrantValidationResult()
{
IsError = true,
Error = ex.Message
};
}
}
#region Private Method
/// <summary>
/// 验证用户
/// </summary>
/// <param name="loginName"></param>
/// <param name="password"></param>
/// <returns></returns>
private async Task<List<Claim>> ValidateUserAsync(string openId, string unionId)
{
//TODO 这里可以通过openId 和unionId 来查询用户信息(数据库查询)，
//我这里为了方便测试还是直接写测试的openId 相关信息用户
var user = OAuthMemoryData.GetWeiXinOpenIdTestUsers();
if (user == null)
{
//注册用户
}
return new List<Claim>()
{
new Claim(ClaimTypes.Name, $"{openId}"),
};
}
#endregion
}GrantTypeConstantsコードは主に定義するために使用される、静的なGrantTypeカスタム認証タイプを、そして可能性が高いので、カスタム認証を追跡するために、以下のように、管理するための統一された場所は、維持しやすいがあります：
public static class GrantTypeConstants
{
/// <summary>
/// GrantType - 微信端授权
/// </summary>
public const string ResourceWeixinOpen = "weixinopen";
}ParamConstants クラスは次のようにパラメータを必要なカスタム認証コードの定義は次のとおりです。
public class ParamConstants
{
public const string OpenId = "openid";
public const string UnionId = "unionid";
public const string UserName = "user_name";
}さて上記のカスタムバリデータは達成されたましたが、十分に、我々はクライアントが承認カスタムのタイプをサポートできるようにする必要はありません、我々は開いてOAuthMemoryDataコードをGetClients以下のように、コードは次のとおりです。
public static IEnumerable<Client> GetClients()
{
return new List<Client>
{
new Client()
{
ClientId =OAuthConfig.UserApi.ClientId,
AllowedGrantTypes = new List<string>()
{
GrantTypes.ResourceOwnerPassword.FirstOrDefault(),//Resource Owner Password模式
GrantTypeConstants.ResourceWeixinOpen,//新增的自定义微信客户端的授权模式
},
ClientSecrets = {new Secret(OAuthConfig.UserApi.Secret.Sha256()) },
AllowedScopes= {OAuthConfig.UserApi.ApiName},
AccessTokenLifetime = OAuthConfig.ExpireIn,
},
};
}クライアントのAllowedGrantTypes設定および許可私はカスタムを追加しGrantTypeConstants.ResourceWeixinOpen、
今もクライアントが設定されているサポート、そして最終的に我々がする必要があるAddExtensionGrantValidator<>メソッド延長自定义授权验证器登録するとDI、次のように、コードは次のとおりです。
public void ConfigureServices(IServiceCollection services)
{
services.AddControllers();
#region 数据库存储方式
services.AddIdentityServer()
.AddDeveloperSigningCredential()
.AddInMemoryApiResources(OAuthMemoryData.GetApiResources())
//.AddInMemoryClients(OAuthMemoryData.GetClients())
.AddClientStore<ClientStore>()
.AddResourceOwnerValidator<ResourceOwnerPasswordValidator>()
.AddExtensionGrantValidator<WeiXinOpenGrantValidator>();
#endregion
}まあ、簡単な授权中心コードのアップグレードが完了している、我々はコマンドラインから実行されている授权中心と用户业务网关する前に、用户业务网关任意のコードを変更せずに、図は次の通りです：
次のことを実行するためのJlion.NetCore.Identity.Server権限
次のようにJlion.NetCore.Identity.UserApiServerユーザーサービスゲートウェイが実行されます
私たちは今、シミュレーション郵便配達員が使用openId、unionId、userNameパラメータ要求を授权中心取得するためAccessTokenの要求以下、：
私たちは、郵便配達を介してアクセスし、認証情報運ぶために持っている用户业务网关データを以下のように、結果は次のとおりです。
まあ、カスタムライセンスモデルが完了している、単に授权中心アップグレードが完了している、上記のWeiXinOpenGrantValidator私は、認証と登録へのデータベースアプローチに直接行かなかったバリデータは、簡単なデモを書き、私たちはTODO高速なデータベースことに興味を持っています操作は、私はgithubの上のコードに提出しており、ここで再び同期戦闘デモの私のブログのアドレスを共有するために、達成するためにhttps://github.com/a312586670/IdentityServerDemo
第四に、思考と概要
Benpian私が学んだ情報に、ソースコードとアクセスを見ることで、カスタム認可を導入IdentityServer4することができ自定义授权、拡張方法も。これは授权中心、カスタムマイクロ手紙今日のOpenIDの認証、SMS認証コードおよび他の認可のカスタム認証の共有などの認証方式の複数のセット、拡張することができApi资源、柔軟でスケーラブルなライセンスモデル、柔軟なアップグレードの可能性のある合併、複数のセットを。私たちが使用しているため、知識Benpianは、小さいが、非常に重要な関与授权中心、多くの場合、認証方法の様々な出会いをし、ユーザアプリケーションの異なるセットが統一されたID認証を使用する許可が缶の原則を習得し、認証能力の異なる方法で切り替え、ここでいくつかのブロガーが要求されますAccentToken、有効期限を行う方法を期限切れになりますか？あなたは、それを再認証してくださいますか？これらの問題は、私は、共有への次の記事を手配します。
魂は尋ねました：
上記授权中心の例では、にそう直接あなたのカスタム使用シナリオの承認とその柔軟性、実際のシーンをより良く理解していただくことを主にopenId、許可の安全を確認するために、その他の関連情報？誰もが思考、どのような場合我々危険な良いの溶液であってもよいですか？自己改善は、自分自身のための思考を停止することです、我々は彼らの思考にプレイを喜ばせることができ、答えは、あなたの参考のために学ぶために、メッセージボードに感謝のまま！！！